Providing services from a remote computer system to a user station over a communications network

ABSTRACT

Methods, systems, and computer program products for providing services from a remote computer system to a user station over a communications network, including automated identification of users. During a first communication session between a user station and a remote computer system, the user station provides first user identification information to the remote computer system. The remote computer system uses the first user identification information in transaction during the first communication session. The remote computer system also stores at least a portion of the first user identification information. The remote computer system also provides second user identification information to the user station, which is stored at the user station. The remote computer system also generates an association between the stored first user identification information and the second user identification information. During subsequent communication sessions between the user station and the remote computer system, the user station automatically provides the stored second user identification information to the remote computer system, that is, without user-prompting. The remote computer system uses the received second user identification information and the association, during the subsequent communication session, to identify and retrieve the stored first user identification information. The remote computer system then uses the retrieved first user identification information in the subsequent transaction.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of co-pending U.S. Application SerialNo. 12/603,229 filed on Oct. 21, 2009 by REISMAN, Richard R. which is aDivision of U.S. application Ser. No. 11/513,329 entitled PROVIDINGSERVICES FROM A REMOTE COMPUTER SYSTEM TO A USER STATION OVER ACOMMUNICATIONS NETWORK filed on Aug. 31, 2006 by REISMAN, Richard S.which is a Continuation of U.S. patent application Ser. No. 09/556,062,filed on Apr. 20, 2000 (pending), which is a Continuation-In-Part ofU.S. patent application Ser. No. 08/982,157, filed Dec. 1, 1997 (U.S.Pat. No. 6,125,388), and 08/641,010, filed Apr. 29, 1996 (U.S. Pat. No.6,594,692), both of which claim priority to U.S. patent application Ser.No. 08/251,724, filed May 31, 1994 (U.S. Pat. No. 5,694,546), all ofwhich are incorporated by herein by reference in their entireties andfor which priority is claimed under 37 C.F.R. §120.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to providing services from a remotecomputer system to a user station over a communications network and,more particularly, to automated identification of users.

2. Background Art

Electronic publication is an exploding industry in which thousands ofnew products including magazines and periodicals, software applicationsand utilities, video games, business, legal and financial informationand databases, encyclopedias and dictionaries are purchased by millionsof customers. Commonly, such information products are replicated incomputer-readable form on magnetic or optical storage diskettes and arebox-packaged with printed manuals for distribution to retail stores anddirect mail sales. These marketing practices are relatively expensiveand involve a significant time lag of at least days or weeks to get aproduct into a consumer's hands once it is created.

Such costs and delays are generally acceptable for original, high valueproducts such as collections of publications or software application, ofwhich some examples are NEWSWEEK® Interactive CD-ROM, or disks, whichprovides a searchable audio-visual library of issues of NEWSWEEKmagazine and CINEMANIA® CD-ROM which provides reviews and otherinformation on newly released films. For time-sensitive, low-valueupdates, for example, the latest issue of Newsweek or last week's moviereviews, distribution in stored form, on physical media, is slow and thecost may exceed the value of the information in the product.

Thus, electronic transfer from a central computer server to asubscriber's computer over common carriers or wide area networks is anattractive proposition. Similar considerations apply to the distributionof software program updates, although cost and frequency of issue arenot such serious constraints. A problem faced in both situations is thatof incorporating the received material with the original material sothat a fully integrated publication, information database or softwareprogram is obtained by the user.

Another class of electronically distributed information productcomprises home shopping catalogues of mail order products distributed onoptical or other digital data storage disks which may contain text,sound and images from printed catalogues or uniquely created material,for example software application demos. To applicant's knowledge andbelief, available products lack any computer order placement capability,requiring orders to be placed by voice call.

Communication between remote computers, not directly interconnected byumbilical cable or a wired network, is enabled by a wide range ofhardware devices and software drivers, utilities, applications andapplication modules. Telephone modems that couple a computer with thetelephone network are familiar devices. RF modems that couple computersinto wireless networks are less familiar but are beginning to appear inconsumer devices known broadly as personal information communicators(PIC's) of which personal digital assistants (PDA's) such as AppleCorp.'s NEWTON® product are a first generation. New kinds of digitalcommunications devices can be expected to emerge as digital technologyreplaces analog transmission.

General-purpose, online, modem-accessed, electronic informationservices, such as PRODIGY, COMPUSERVE and AMERICA ONLINE (trademarks),and some Internet services, provide wide access to timely informationproducts from a central server, but are limited and complex. Theyprovide no means for the integration of downloaded information withinformation products offered on disk or CD, and provide only rudimentaryfacilities for local viewing and search of downloaded files.

Such online information services provide their own user interface whichis generally unlike that of a disk or CD-based information product, andcan be customized very little, if at all, by a publisher using theservice for product distribution.

Online services are oriented to extended online sessions which requirecomplex user interaction to navigate and find desired informationobjects. Initial setup and use is rendered complex by requirementsrelated to extended session use of data networks and the frequent needto navigate across the network, and through massive data collections, tolocate desired data items. General-purpose online information servicesdo not provide a suitable medium for electronic information publishersto distribute updates, and the like, because of limited interfaceflexibility, because a publisher cannot expect all their customer baseto be service subscribers, and because of cost and payment difficulties.Such services are centered on monolithic processes intended for nationaluse by millions of subscribers which processes are not readilyadaptable.

Online service charging mechanisms are also inflexible and inappropriatefor most individual information products, requiring monthly subscriptionfees of $5-10 or more, plus time charges for extended use, which arebilled directly to users, after a user sign-up and credit acceptanceprocess. Such cost mechanisms are too expensive and too complex fordistribution of many products such as magazine and other low cost updateproducts. They do not presently permit a publisher to build an accessfee into a purchase price or a product subscription.

Recent press announcements from corporations such as AT&T, Lotus,Microsoft and MCI describe plans for new online services providing whatare called “groupware” services to offer rich electronic mail and groupcollaboration functions, primarily for business organizations. Althoughoffering multiple electronic object transport operations such servicesare believed to have complex setup procedures and software requirementsand complex message routing features and protocols, and to lackinterface flexibility. Accordingly, they are not suitable for massdistribution of low cost electronic information update products.

Communications Products

Many software products exist that enable one computer to communicatewith another over a remote link such as a telephone cable or the airwaves, but none enables a vendor substantially to automate commoncarrier mass distribution of an electronic information product to acustomer base employing multiple heterogeneous systems withindeterminate hardware and software configurations. Two examples ofpopular such software products are Datastorm Technologies, Inc.'sPROCOMM (trademark) and CENTRAL POINT COMMUTE (trademark) from CentralPoint Software, Inc. which are commonly used to provide a variety offunctions, including file transfers between, interactive sessions from,host-mode services from, and remote computer management of,modem-equipped personal computers wired into the telephone network.

Counterpoint Publishing's Federal Register Publications

Counterpoint Publishing, (Cambridge Mass.) in brochures available to theapplicant in November 1993 offered electronic information productsentitled “Daily Federal Register” and “CD Federal Register”.” “DailyFederal Register” includes communications software and a high-speedmodem. Apparently, the communications software is a standard generalpurpose communications package with dialing scripts that are customizedto the needs of the Federal Register products. Accordingly, the cost ofa communications package license which may be as high as about $100 atretail must be included within the product cost. Also, CounterpointPublishing avoids the difficulties of supporting various modems byproviding its own standard modem, with the product, building in a cost(about $100-200) which renders this approach quite unsuitable formass-market distribution of low cost electronic information updateproducts. The resulting product is not seamless either in its appearanceor its operation because the communications software is separatelyinvoked and used, and has its own disparate look and feel to the user.

The “CD Federal Register” provides the Federal Register on CD-ROM atweekly intervals for $1,950.00 and CD-ROM disks are shipped to customersas they become available. Back issues are $125 each. Updates areprovided by shipping a disk. The Federal Register is a high-valueproduct intended for specialist, business, academic and governmentalusers. Distribution of updates on CD-ROM, as utilized by CounterpointPublishing, is not a suitable method for lower value products such as aweekly news magazine, because of the associated costs. Shipping delaysare a further drawback.

While the two product “CD Federal Register” and “Daily Federal Register”might be used together, at an additive cost, to provide a combination ofarchives on CD-ROM plus daily updates obtained and stored until replacedby a new CD-ROM, based on information available to the present inventorit appears that the two products must be used separately. Thus they mustapparently be viewed, searched, and managed as two or more separatecollections, requiring multiple steps to perform a complete searchacross both collections, and requiring manual management and purging ofthe current collection on hard disk by the user.

Xcellenet's “REMOTEWARE”®

Xcellenet Inc. in product brochures copyrighted 1992 and a price listdated Aug. 16, 1993, for a “REMOTEWARE”® product line, offers a range ofREMOTEWARE® software-only products providing electronic informationdistribution to and from remote nodes of a proprietary REMOTEWARE®computer network intended for use within an organized, corporate orinstitutional data processing or management information system. Thesystem is primarily server directed, rather than user initiated andrequires an expensive program (priced at $220.00) to run at the user'snode whereas the present invention addresses consumer uses which willsupport costs of no more than a few dollars per node.

Furthermore, REMOTEWARE® is primarily intended to be used with otherREMOTEWARE® products at the node which other products provide a range ofuser interface and data management functions, at significant additionalcost, each with their own separate user interface presenting a standardREMOTEWARE® look and feel. In addition, the nodes require asophisticated central support and operations function to be provided,which may be difficult for an electronic information publisher toaccomplish and add unacceptable expense.

REMOTEWARE® is overly elaborate to serve the simpler objectives of thepresent invention. Designed for the demanding needs of enterprise-widedata processing communications, the client or node package provides manyfunctions such as background operation, ability to receive calls fromthe server at any time, ability to work under control of the centralserver to survey and update system software and files and an ability tosupport interactive sessions, which abilities are not needed to carryout the simpler information transport operations desired by the presentinvention. Such capabilities may be desirable in an enterprise MISenvironment, but are not appropriate to a consumer or open commercialenvironment, and bring the drawbacks of complexity, cost, and programsize, which may put undesirable operational constraints on the user (andperhaps even compromise the user's privacy). REMOTEWARE® is too costlyand complex for mass distribution of updates to periodicals, cannot beshipped invisibly with an electronic information product and requiresspecialized server software and operations support that would challengeall but the largest and most technically sophisticated publishers.Accordingly, REMOTEWARE® is unsuitable for widespread use as aneconomical means of distributing updates for a variety of electronicinformation products.

Although it has wider applications, a significant problem addressed bythe invention is the problem of economically distributing updates ofelectronic information products to a wide customer base that may numbertens or hundreds of thousands, and in some cases, millions of consumers.At the date of this invention, such a customer base will normallyinclude an extensive variety of computers, operating systems andcommunications devices, if the latter are present, all of which may havetheir own protocols and configuration requirements.

While an electronic information product vendor might consider licensingor purchasing an existing commercial communications product fordistribution with their publication product to enable remote, disklessupdating, the high cost of such a solution would generally beunacceptable because a communication package includes a broad range offunctionalities not required for the vendor's particular purpose, forexample, remote keyboarding. Significantly, a commercial communicationspackage is not susceptible to customization of its user interface andmay have its own configuration requirements and installationrequirements, with regard to directories, device drivers and the like,which are incompatible with other vendor or user requirements or aresimply a nuisance to the user. Thus, a commercial communications productin addition to its cost, cannot be satisfactorily integrated with aninformation product.

There is accordingly a need for computer-implementable informationtransport software to enable simple, economical and prompt massdistribution of electronic information products.

BRIEF SUMMARY OF THE INVENTION

The following summary provides an understanding of at least some aspectsof the invention. The summary is not an extensive overview of theinvention. It is not intended to identify key or critical elements ofthe invention nor is it intended to delineate the scope of theinvention. Its sole purpose is to present some concepts of the inventionin a simplified form as a prelude to the more detailed description thatis presented later.

Methods, systems, and computer program products for providing servicesfrom a remote computer system to a user station over a communicationsnetwork include automated identification of users.

During a first communication session between a user station and a remotecomputer system, the user station provides first user identificationinformation to the remote computer system. The remote computer systemuses the first user identification information in transaction during thefirst communication session.

The remote computer system also stores at least a portion of the firstuser identification information. The remote computer system alsoprovides second user identification information to the user station,which is stored at the user station. The remote computer system alsogenerates an association between the stored first user identificationinformation and the second user identification information.

During subsequent communication sessions between the user station andthe remote computer system, the user station automatically provides thestored second user identification information to the remote computersystem, that is, without user-prompting. The remote computer system usesthe received second user identification information and the association,during the subsequent communication session, to identify and retrievethe stored first user identification information. The remote computersystem then uses the retrieved first user identification information inthe subsequent transaction.

Further embodiments, features, and advantages of the present invention,as well as the structure and operation of the various embodiments of thepresent invention, are described in detail below with reference to theaccompanying drawings. These aspects are indicative of but a few of thevarious ways in which the principles of the invention may be employed,and the present invention is intended to include all such aspects andtheir equivalents. Further features and advantages will be apparent to aperson skilled in the art based on the description set forth hereinand/or may be learned by practice of the invention.

It is to be understood that both the foregoing summary and the followingdetailed description are exemplary and explanatory and are intended toprovide further explanation of embodiments of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form partof the specification, illustrate aspects of the present invention and,together with the description, further serve to explain principles ofthe invention and to enable a person skilled in the pertinent art tomake and use the invention.

FIG. 1 is a schematic diagram an information transport softwarecomponent installed in a computer workstation and communicating with acomplementary server-resident software module for distribution ofelectronic information objects.

FIG. 2 is a flow chart of an information transport operation performedby the software component and module of the embodiment of FIG. 1.

FIG. 3 is a schematic diagram of a server-based electronic distributionservice employing an information transport software component.

FIG. 4 is a further schematic diagram of the service illustrated in FIG.3.

FIG. 5 is a schematic diagram of a conventional communications productemployed to transport an information object between a user and a remoteserver.

FIG. 6 is a schematic diagram similar to FIG. 5 showing, in acomparative manner, some of the benefits that can flow to a user when aninformation transport software component, such as that described withreference to FIG. 1, is used for a similar transport operation.

FIG. 7 is a schematic diagram of a basic object retrieval embodiment ofthe invention.

FIG. 8 is a schematic diagram of a product-integrated interfaceembodiment of the invention.

FIG. 9 is a schematic diagram of a server-enhanced embodiment of theinvention.

FIG. 10 is a schematic diagram of an embodiment of the inventionproviding update objects via a commercial service.

FIG. 11 is a schematic diagram of a multiple service routes embodimentof the invention.

FIG. 12 is a schematic diagram of an offline Web browser embodiment ofthe invention.

FIG. 13 is a schematic flow diagram of a hyperlink readdressing orredirection process according to an aspect of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention now will be described more fully hereinafter withreference to the accompanying drawings, in which embodiments of theinvention are illustrated. The invention may, however, be embodied inmany different forms and should not be construed as limited to theembodiments set forth herein. Rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the invention to those skilled in the art.

In the following detailed description, numerous specific details are setforth in order to provide a thorough understanding of the invention.However, it will be understood by those skilled in the art that thepresent invention may be practiced without these specific details. Inother instances, well-known methods, procedures, and components have notbeen described in detail so as not to obscure the present invention.

Referring to FIG. 1, the inventive software component is schematicallyshown in operative mode installed at a user's computer workstation. Theworkstation is communications-equipped for communication with remoteservices, for example by modem, which services are also shownschematically. Only relevant software and hardware components of thesystem are shown.

Relevant components at the workstation comprise operating systemservices 10, a containing information product 12, an informationtransport component or module 14, herein also referenced as a“transporter” which may be a stand-alone product or, in preferredembodiments is embedded or contained in the containing informationproduct 12. Information transport component 14 provides a generalpurpose facility for sending and fetching information objects between anend user's computer (the client) and a central server. Informationtransport component 14 is not customized to the containing informationproduct 12, but is intended to be used in conjunction with any of a widerange of electronic information products.

Operating system services 10 provide capabilities for the containinginformation product 12 and the information transport component 14 toaccess a readable information storage device 16 which may, for example,be an optical disk drive such as a read-only CD-ROM where productinformation 17 is stored. In addition, a read/write information storagedevice 18, for example, a conventional hard disk is accessed via theoperating system services 10 for storage of a fetched additionalinformation object 26. The storage media used for hard disks and thelike are often described as nonvolatile and the type of storage isfrequently referenced as “permanent.” however, the more recently usedterm “persistent storage,” which references the manner of storage aswell as the physical storage media and distinguishes from transientstorage where objects may be automatically erased after some interval,or event, without supervisory control or awareness of the erasure, is amore suitable descriptive term for the purposes of the presentinvention.

As necessary, different, or modified, information transporter components14 can be supplied for users of different operating systems or systemfamilies, notably DOS (available in several versions, for example fromMicrosoft Corp, IBM Corporation, Novell, Inc.) Windows (trademark,Microsoft Corp.), Apple Computer Corp.'s operating systems, possibly IBMCorporation's OS/2 (trademark), and any distinct operating systemsdeveloped for personal digital assistants, pen-based computers and thelike.

Information transport component 14 also uses operating system services10 for external communication with a communications network 20 throughwhich the information transport component 14 can access a remote server22, or server-client network, supporting a data storage device 24 wheredesired additional information object 26 is located.

Communications network 20 can be any electronic distribution systemsuitable for transporting information objects 26 including wired andwireless common carriers such as telephone networks, cable televisionsystems or networks and mobile telecommunications or data communicationsnetworks and extends also to emerging and future systems of providingelectronic communication between users of diversified equipment. Theterm “common carrier” is used herein to embrace all such datacommunication systems as will reasonably meet the purposes of theinvention. The term “modem” is used herein to embrace any networkinterface device enabling a user station to communicate on such acommunications network 20.

While the containing information product 12 can take many differentforms, as described herein, and as will also be apparent to thoseskilled in the art, a preferred embodiment is that of a periodicallyissuing publication or publications, for example, a news magazine or acollection of patents. Again, the additional information object 26 couldbe any information of interest to the user, having some relevance to thecontaining information product 12, but the invention and its uniquecapabilities enable the additional information object 26 to be fullyintegrated with the containing product 12 in a manner that can beautomated to be transparent to the user.

The inventive information transport component 14 is designed to requirea minimum of user input. A bare minimum will be a user's ID which can beentered by the user in a product setup and automatically accessed forinformation transport, or could by pre-loaded by the vendor from datasupplied by the user at purchase.

A product ID is preferably pre-loaded into the containing informationproduct 12 by the information product vendor or publisher to beavailable for use by the information transport component 14. However,even this may not be required. In an alternative embodiment, the productID can be automatically incorporated into the product in a productreplication process that permits individualized coding of unique ID's.In most cases, a user-actuated menu selection is provided in thecontaining information product 12 after integration with the inventiveinformation transport component 14 to activate transport of anadditional information object, and preferably, selection of transportactivation drops down a menu of transport choices such as “FETCHUPDATE”, “FETCH CATALOG OF UPDATES”, “SEND DATA” and the like, each ofwhich then runs automatically upon selection.

Updating can also be totally automatic, and other than an obviouslydesirable user notification, be completely invisible to or transparentto the user, running in background on their system, while the user'sscreen is available for other processing such as running the containinginformation product 12. Where updates are made available on a knownschedule, a totally automated product can be provided that fetches anupdate without any user intervention, on the specified release date, oras soon thereafter as the user's system, or the containing informationproduct 12, is activated. In practice, most users will probably preferan opportunity to confirm that the fetch transaction should proceed. Apreferred embodiment monitors the user's system clock and alerts a userto the arrival of an update release date and asks the user to confirmthat the system should seek and fetch the scheduled update, ifavailable.

Thus, the invention is particularly suitable for importing updates ofinformation or information processing products, such as periodicallyissuing literature, or software upgrades. Accordingly, additionalinformation object 26 preferably comprises updates which can beintegrated with the information product 12 to provide, for example, acoherent body or continuous sequence of materials that can be commonlysearched and indexed preferably in a manner giving the user theappearance of a common logical file formed from physically distinctfiles. The appearance of integration can be achieved by searching newand then old indexes in series and making the search and navigationlogic of the containing product smart enough to combine new and oldinformation. For example a new object can have an index file similar tothat for the original information product 12. A search engine can firstsearch the new index, then the old one, and then produce a combined setof results. Preferably, the files are not actually merged or otherwisecombined as to do so could be unduly complex.

As shown in FIG. 1, the containing information product 12 comprises auser interface 28 enabling the user to view, search, excerpt and printor otherwise export or process selected information items from productinformation 17. The user interface 28 provides standard informationproduct features, as conventionally supplied by the product publisher,supplemented by appropriate fetch or send options to activate thefeatures of the inventive information transport component 14.

Also shown in FIG. 1 are a database management module 30 and a datastructure definition module 32. Database management module 30 providesretrieval-oriented database processing of the information productincluding indexed searching and selective retrieval capabilities usingone or more index keys such as an issue or item number, or full textsearching, and may provide hypertext and hypermedia linkages. The datastructure definition 32 provides the database structure of relevantfiles as classified by field or element, name, type, size and the like.After successful completion of a fetch operation, control is returned tocontaining information product 12 to process the new information inessentially the same manner as the original information, or in any othermanner for which it has been equipped.

Major modules comprised in the inventive information transport component14 are a user interface 34, a communications module 36 and fetch-sendprotocol 38. In addition, the information transport component 14preferably comprises its own built-in application programming interfaces(APIs) such as a user interface API 40 and a communications API 42,enabling the information transport component 14's user interface andcommunications modules respectively, readily to be incorporated with, orplugged into a wide range of containing information products 12. Suchincorporation, in the currently best known embodiment of the invention,is effected by software engineers familiar with and having access to thecontaining information product 12, but future developments may enablethe incorporation process to be effected by skilled users.

References herein to an applications programming interface (API) will beunderstood to embrace any program interconnection technique whichsupports direct, seamless interaction between one program and another,including procedural calls, object encapsulation, or emerging techniqueslike Microsoft Corp.'s Object Linking and Embedding (OLE) or AppleComputer's Open Doc.

API 40 is responsible for providing means for the user to interact withthe information transport functions of the invention and interface asseen by the user and API 42 is responsible for handling internalprocesses of communications and data management.

The APIs 40 and 42 are intended to enable the information transportcomponent 14 to be used by a range of product programs controlling avariety of information products and to enable each API 40 and 42 to befree to exercise flexibility and creativity in extending its associateduser interface 28, data management module 30 and database structure 32to fully address the provision of transport functions for the purposesdescribed herein.

API 42 operates on a transport function level involving high levelinteractions between the containing product 12 or the user (or theoptional user interface) and the transporter 14 before and aftercommunications while the detailed low-level interactions between thetransporter client and the server during communications are handled byfetch-send protocol 38, without involvement of the containing product 12or the user. “High level” is used to refer to a level at which softwareinteracts with a user, typically in simple, readily comprehensible,function-oriented, graphic or everyday language terms, while “low-level”refers to a level of detailed procedural interaction with an operatingsystem, or device (modem, port etc.) in obscure program or machinelanguage terms incomprehensible to most users.

Fetch-send protocol 38 is, in the preferred embodiment shown, acomponent of a novel client-server communications procedure designed tomanage the transaction-oriented transmissions required to achievesatisfactory transport of desired server stored information objects, andoptionally, central reporting of user information in a predeterminedformat. Alternatively, one or more existing protocols could be used.

Preferably, the API's 40 and 42 and the fetch-send protocol 38 arestructured to use a manifest list to control the exchange of informationobjects. The manifest list can be provided in fetch-send protocol 38,and can be forwarded to remote server 22 to provide better efficiency,error control, and management of the operation. Alternatively themanifest list may remain resident at the user's station. The manifest isvaluable operating at the client station, at the API level, to specifythe actions required during a transport session and can in oneembodiment comprise a list of send and fetch operations which areindividually controlled.

This software mechanism, employing novel communications procedures andapplications interfaces that reference an object manifest, provides anew way for performing a wide variety of information exchange functionsin a simple, standardized and economical manner.

API Functions: (1) Product Setup

In preferred embodiments, API 40 and API 42 include a product setuproutine of an application-specific configuration, which is used by thepublisher or product developer, prior to publication, to establishseamless compatibility between the containing information product 12 andthe information transport component 14 for smooth execution of desiredtransport functions. A completion status code is also specified.

The application-specific configuration posts user and product IDinformation, as needed to process password or other access codeauthentication and posts files information, including designation of anapplication work directory and a transporter work directory forperforming the transporter functions of information transport component14.

Additionally, the application-specific configuration sets up anappropriate decompression (or compression for send objects) techniqueaccording to the expected format and condition of fetched informationobjects 46, which information is pre-coded into communications component36.

The application-specific configuration established through API 40selects either a standard user interface, as furnished with informationtransport component 14, or an application-controlled user interface.Control settings are established for connection problem handling, diskerror handling, abort and server condition handling, access denial,unavailability of information object files and any other errorsituations which may occur during transport.

If desired, optional, advanced controls for scheduled automatic callingcan be included in the application-specific configuration used inpreparing the containing information product 12 for publication.

Preparation of containing information product 12 and incorporation ofinformation transport component 14 therein, with an application specificconfiguration, as described is carried out prior to publication to builda customized, ready to run version of the product with automated updatecapability.

Communications API 42 establishes a product-specific transport methodchoice list for selection of an appropriate file transfer protocol asbetween direct dial, data network dial, and other modes of transport.Communications protocols specify necessary connection parameters such asaccess number and network addressing or other routing information.Optional script choices can provide for different modes of transport.

These product-specific configurations and protocols enable informationtransport component 14 to be packaged in executable form with containinginformation product 12, with all necessary product-specific componentsand settings, including a standard user interface if selected, ready forinclusion in the product package.

If desired, at the option of the information product publisher, astandard user interface may be included. Such an optional standard userinterface can have all facilities needed to select transportable objectsfrom a predefined list, perform all user setup functions, and invokeinformation object transport.

Additional options are standard software that would allow the user tosearch, view and print the transported objects totally independently ofthe user interface and database search components of the containingproduct. Both such options enable a publisher to exploit the inventivetransport product for efficiently and economically providing updateswithout having to make changes to the publisher's containing product,simply by configuring the transporter or information transport component14 and physically including it, and the optional components, within thecontaining product.

A standard viewer might handle only ASCII text, but it preferably couldprovide for other useful formats such as standard word processor,spreadsheet or database formats, or multimedia formats such as video,sound and HTML (hypertext markup language), a format becoming popular onthe Internet and which provides the ubiquitous Web pages for theInternet's World Wide Web.

API Functions: (2) User Setup

Compatibility with the user's system is effected by API 40 establishinga user-specific configuration, and creating or updating the necessarycontrol files.

Parameters established in the user-specific configuration include asetup ID number to permit use of multiple setups, for example, fordifferent transport options, and a product ID number.

The user-specific configuration posts user ID information and a passwordor other access code authentication and posts files information,including disk and drive designation for work and data directories.Autocall options and a completion status code are also specified.

API 40 provides information for communications module 36, specifying auser communications protocol for the user's hardware, operating system,line configuration, and so on. Thus, for a standard telephoneconnection, comm port, speed (baud rate), interrupt settings, modem typeand control strings, dial prefix, dial 9, pulse or tone, call waitingshut-off, and the like are specified, as appropriate. Additionally, theuser communications protocol includes access number and connectionparameters, optionally with script selection for routing choices viadata networks, and so on.

The resultant user-specific configuration and communications protocolsgenerated through API 40 create a setup ready to call and places it inthe designated transporter work area.

A validation procedure checks entries and reports obvious errors inparameter settings.

Preferably, multiple product ID setups are provided to enable multipleinformation products to use the transporter with an appropriate,compatible transporter version. Preferably also, the user-specificconfiguration accommodates shared use of the transporter work areas bymultiple information product applications resident on the same user'ssystem.

Mechanism of Fetch-Send Protocols 38 (User) and 44 (Server)

User fetch-send protocol 38 working in cooperation with serverfetch-send protocol 44 controls the desired information object transportfunction, calling remote server 22 and exchanging data objects. Itperforms or supervises communications between the user's system andremote server 22.

Communications module 36 uses a setup ID number specified through API 40or 42, selects which setup to use for a call, calls remote server 22using protocol 38, and in a preferred embodiment, sends an objectmanifest comprising a send object list, a fetch object list or both.Such manifest is created under control of user interface 28 from apre-existing set of choices supplied with the product or obtained duringprevious update operations, or both.

Alternatively fetch-send protocol 38 may refer to a pre-existingmanifest list stored at the user's station, or may be directed by remoteserver 22 to select one of multiple pre-existing manifest lists storedat the user's station. As another alternative, although it is convenientand advantageous to transmit the manifest list to the server 22, therelevant status and management information can simply be used locally bycommunications module 36 and be integrated into the individual fetch andsend protocols.

A send object list comprises object action codes specifying the type ofserver action required, if any, object names, object sizes and responseobject size, if any. A fetch object list comprises object names, objectsizes and an object availability date.

A completed object manifest is employed to convey the status of thetransport operation and to provide for additional information transport,if desired. The completed object manifest adds the following to therequest object manifest: send object additional information; objectacceptance codes returned by server 22; time of acceptance; and aresponse object name, if called for by the object action code.

For a fetch operation, the completed object manifest adds the followingto the request object manifest: fetch object additional information; afetch confirmation or failure code; the time of completion or failureand a revised availability date if the requested fetch object wasunavailable.

If a scheduled update or polling option is present and selected, ascheduling or polling indicator is included, and a completion ofprocessing or import function to call through API 42 is specified.

A completion status code terminates the fetch or send operation andreturns control to the information product application or the provideduser interface.

Information Transport Using Communications Module 36

Communications module 36 employing the described fetch-send mechanismcomprised by cooperating protocols 38 and 44 performs the functionsnecessary to complete an information transport operation, as describedherein, under a variety of circumstances, with tolerance for a commonrange of error conditions, open drives, inadequate disk space, lost lineconnections and the like, without losing control of the user's system.Using correct, verified ID, naming and routing information, theinformation transport operation employing the inventive informationtransport component 14 is less error-prone than many computer userswould be were they effecting the transport operation with conventionaltechnology requiring them to enter routing and storage information andthe like, manually.

Communications module 36 verifies that all send objects are asspecified, that all fetch objects are scheduled to be available,verifies that sufficient disk space is available for all fetch objectsand for compressed transmission copies of all objects, and returns anerror report if any of these requirements is not fulfilled.

Communications module 36 performs communications, then returns acompleted object manifest, and logs all activity in a transporter logfile. If an optional scheduling/polling feature is selected, thecommunication is deferred until the scheduled time.

These general objectives are achieved by carrying out the followingprocess steps after an application (or optionally a transporter userinterface) requests a transport function:

-   -   1) Local validation of the request returning a failure code if        the request is improperly specified.    -   2) Compression of all send objects for transmission and placing        them in the designated transporter work area.    -   3) Connection attempts to remote server 22, returning a failure        code if necessary. Connections are made via phone line or        network. The system handshakes and identifies the call to the        server.    -   4) Presentation of the object manifest, if utilized, for        validation and action.    -   5) On receiving a go-ahead, transport of each send object,        logging each as sent, and receipt of object acceptance codes        from the server and logs them, when received.    -   6) Receipt of all fetch objects from the server, placing them in        the transporter work area, and logs them as received. Fetch        object names may be precise, or generic or alias names may be        used to request a latest installment.    -   7) Receipt and logging of a completed object manifest from the        server. (If receipt of response objects is implied by the action        codes, first receives a revised object manifest, and fetches the        response objects, then receives the completed object manifest.)    -   8) Disconnection from server.    -   9) Decompression and unpacking of all fetch objects into        application work area, and logs completion status.    -   10) Returns control to the application (or optional transporter        user interface).

The product checks the completion code, and completed object manifest todeal with any error conditions. The application performs any requiredimport processing on fetched objects to integrate the data and indexeswith prior data, as desired, to enable seamless use. If desired, importprocessing can include, or offer as a user selection, file maintenancefunctions relevant to the information product including, for example,file purging to remove obsolete information files and preserve theuser's storage space. Specifications of files to be deleted can beincluded with the original product or with a fetch object. In eitherevent the responsibility for accurate specification is passed to thevendor, relieving the user of the risk of making erroneous deletions andanxiety attendant thereon. After such import processing the containinginformation product (or the optional separate user interface) thenreturns control to the user for use of the received data.

Those skilled in the art will appreciate that the identification offiles in the object manifest, or for file maintenance functions as theuser station, or for any other purpose of the invention, can be effectedgenerically, for example by using wild card characters, as is customaryin file specification, and which effectively permits multiple objects tobe specified as a class related by file name characteristics, or relatedindividually, thereby providing options for specifying of such class ofmultiple objects to proceed at one time or in a series of transportsover time. Other algebraical identification methods can be used whichmay reference object versions in series or comparable characteristics.

The foregoing steps are illustrated in the flow block diagram of FIG. 2.When containing information product 12 issues an information transportcall 50,51, setup filter 52 runs setup routine 54 if this is a firstcall and no information transport setup was run on installation ofcontaining information product 12. At block 56, an object manifest isretrieved for pre-transport preparation at block 58. After prepping, acall to server 22 is established at block 60 and when the connection ismade, and a handshake performed, one or more objects is transported atblock 62.

After completion of transport and receipt of a completion manifest,server 22 is disconnected at block 64, received objects are decompressedand unpacked at block 66 and stored in a designated disk storagelocation at block 68. Object storage triggers containing informationproduct 12's import processing to assimilate the information update withthe original information product at block 70, following which acompletion report is issued at 72 and control is returned to thecontaining information product 12 at 74.

Optional Schedule Function

An optional transport function module for scheduled or poll-responsiveinformation object transport can be provided to defer the fetching of anupdate or to defer another information transport operation to aspecified later time, or until called by the server.

The optional transport function schedules a request, waits, thenautomatically performs the transport operation at the scheduled time. Inpolling mode, it activates (and, if necessary, interrupts and thenreactivates) the user station's ability to receive calls.

Mechanics of the optional transport function include a request for an IDnumber, an indicator for calling or polling mode and a scheduleiterating a call time, a retry protocol, call activation and timing,along with an authentication procedure for the server and a completionstatus code.

Client-Server Communications Protocol

Communications between the information transport component 14,functioning as a client, and the server 22 follow a predefinedcommunications procedure having cooperative user components comprisinguser fetch-send protocol 38 and server fetch-send protocol 44.

Server-client intercommunication can be broken down into five steps, a)login, b) manifest transmission, c) send operation, d) fetch operationand e) logout, as described in more detail below.

a) Login

Login establishes a session with an authorized client. A handshakeprocess between user protocol 38 and server protocol 44 identifies theuser's transporter client system to remote server 22 by product ID anduser ID, and a password or other authentication code. A failure reasoncode is given to rejected clients.

b) Manifest Transmission

Preferably, via user protocol 38, the user system issues an informationobject transport request manifest to server 22. Server 22 verifies itsability to meet the request by returning a manifest acknowledgmentspecifying which elements will be processed and provides reason codesfor declined elements. Alternatively, as stated previously, manifestfunctions can be listed in individual send and fetch protocols.

c) Send Operation

If the user system outputs a send object, through information transportcomponent 14 and protocol 38, server 22 receives and accepts the sendobjects and stores them, identified by product ID and user ID. Errorcontrol and retry mechanisms are employed and successful receipt of thesend object is acknowledged and logged.

If the action code calls for a response object, the server obtainsnecessary processing from a pre-designated external source(corresponding to the product ID and action code) and returns theresponse as a fetch object, called a response object.

d) Fetch Operation

The server obtains requested fetch objects by product ID and object nameand forwards them to the transporter at the user. Error control andretry mechanisms are employed and successful transmissions areacknowledged and logged.

e) Logout

The server transmits the completed object manifest to the transporter,confirms and logs receipt, and ends the session.

The Inventive Transporter Compared with a Conventional CommunicationsProduct

FIGS. 5 and 6 illustrate schematically the simplicity and ease-of-usebenefits the invention provides FIG. 6 to a user 100 in fetching aninformation object from a remote server 22 as compared with the use of aconventional communications product (FIG. 5), such, for example, asCENTRAL POINT COMMUTE (trademark) or PROCOM (trademark).

In the prior art embodiment of FIG. 5, many operations require activeparticipation by the user who, for example, must at least initiate anypre-transport preparation 104 of the information object, such aschecking the specifications, checking work space available to store afetched object and conducting any other preliminary checks. The user hasto activate a communications product 102, specify a call route, andafter the call connection is established, specify the objects andinitiate a transport operation. Communications product 102, operating ina cooperative manner with remote server 22, will execute establish callconnection 60 after the call route (phone number) has been specified andwill execute transport objects 62 after the objects to be transportedare specified by the user. Disconnection 64 is usually effected by auser executing a call termination command, which if the user isinattentive, or inefficient, may be delayed longer than necessary tocomplete the transport operation, running up unnecessary line or airtime charges.

After completion of the transport operations, user 100 has to deactivatethe communications product 102 and then initiate any required storingand processing of the fetched product 106. While some of these steps maybe automated via one or more batch files, scripts or macros, a vendor ofa containing information product 12 has great difficulty in furnishingsuch a batch file or macro for a mass market distribution because of thedifferent systems and communications products encountered in a massmarket, which systems and products have a variety of differentspecifications, performance characteristics and unique, incompatiblescripting languages.

Equally, while some more skilled users 100 might be able to write theirown batch files without undue difficulty to automate some of thesesteps. Many users will lack the ability or the inclination to do so.Also the effort would not be justified for a single transport operation.Nor is the result of such efforts likely to match the ease andsimplicity of the results achieved by the present invention whichenables even a first update to be obtained effortlessly with thesoftware running in unattended mode, after initiation.

FIG. 6 clearly shows how the inventive information transport component14 relieves user 100 of many tedious communication functions such asactivating a communications product, specifying a call route, specifyingthe objects to be transported and deactivating the communicationsproduct. In addition, preferred embodiments of the invention alsorelieve the user of optional pre-transport preparation 104 and executionof store-and-process-fetched-product 106 if these functions areappropriate to the containing information product.

Referring to FIG. 6, user 100 selects a transport operation from a userinterface screen in containing information product 12, whereupon thelatter calls information transport component 14 to activate transport.Information transport component 14 implements any necessarypre-transport preparation 104 and then, employing its own communicationsmodule 36, and server fetch-send protocol 44, proceeds in unattendedmode, without requiring user intervention to establish call connection60, to execute transport object 62 and automatically perform adisconnect 64, as described herein.

Automatic transport control and disconnection is a useful feature of theinvention providing economy of line or air time charges and reducingcongestion on the communications carrier. Using conventionalcommunications products, (especially with online services) the durationof the connection may be unnecessarily extended by the delays andpotential errors inherent in user control, resulting in increasedcommunications costs and failures. The inventive transporter 14 providessoftware control of the connection duration, enabling it to be confinedto a period sufficient to effect said unattended object transfer,enhancing efficient use of the communications medium.

Also as described, the operation can be monitored or controlled byemploying an object manifest and is facilitated by the use ofpre-specified addresses and transport characteristics. Aftersatisfactorily completing the transport, the information transportcomponent 14 automatically deactivates and returns control to containinginformation product 12, preferably with a satisfactory completion reportwhich containing information product 12 notifies to user 100 through thecontaining information product 12 user interface.

If the transport object 62 was a product update, optionally astore-and-process-of-fetched-object 106 is initiated by informationtransport component 14 and execution of the store and process operationmay be passed to the containing information product 12. The user can nowuse the updated product.

As FIG. 6 shows, when read, in comparison with FIG. 5, the inventionenables a user 100 to be relieved of all duties save for minimalselection and notification functions, while no complex addedfunctionality is demanded of containing information product 12. Optionalstore-and-process-orprocessor-fetched-object 106 is contemplated asrequiring only minimal modification of existing containing informationproduct 12 functions while other more complex procedural and detailedtransport related functions are handled by the information transportcomponent 14.

Some non-limiting examples illustrative of practical commercial andindustrial applications of the invention will now be described.

Example 1 A News Magazine Distributed on CD-ROM

Some weekly news magazines offer subscriptions to a quarterly CD-ROMwhich contains multimedia material plus a searchable full-text databaseof the most recent quarter's weekly magazine issues and enablingapplication software. Newer issues are not provided until the nextquarterly disc is mailed. Accordingly the CD-ROM electronic magazineproduct steadily becomes out of date and its value lessens.

The invention incorporates an information transport component 14 with anews magazine product stored on a CD-ROM 16, to enable a user to fetchan information object 46 in the form of new issues (and their associatedsearch indexes) from a remote server 22, as they become available, forexample weekly. The fetched updates are stored on a consumer's computerhard disk storage device 24. Because of the size of rich contentmultimedia files, the updates are limited to text material includingfull texts of interim issues and associated files such as indexes.Because it knows the storage location of the updates, the next CD-ROMissue can include, as an install option, or upon first access, a requestto delete the old now-outdated updates from hard disk 24, creating spacefor new updates.

User interface 28 in conjunction with user interface 34 contains codeproviding a menu selection enabling a user to activate the update fetchoperation and then to provide integrated or seamless access to thecombined data, searching both the hard disk storage device 24 and theCD, using both sets of indexes, so that the contents are viewable as asingle collection, although an additional independent searching/viewingfunction for the updates could be provided, if desired.

A product setup routine adapts the information transport component 14 towork with the news magazine CD-ROM's existing software for creation of auser interface, searching and viewing. Communications options may belimited to direct telephone dial only. A simple user interface additioncontrols a setup process allowing the user to enter a unique user ID,provided with each copy of the CD-ROM distribution disk, and to createpredetermined work areas on the user's hard disk.

A schedule of updates with names, dates, and files sizes is provided inthe containing news magazine product on the CD-ROM and is accessed viauser interface 28 in conjunction with user interface 34 to create afetch object manifest 48.

Optionally, user interface 28 in conjunction with user interface 34creates a send object manifest 48 to control transport of userdemographics for market analysis or for renewals, or the like, in theopposite direction from the user to the server, with the send operationbeing triggered whenever the next transport operation is activated, oroptionally, by allowing by allowing the user to trigger it.

A fetched information object 46, such as an update, is automaticallydecompressed and stored on hard disk storage device 18 as additionalinformation object 26 for integration with the original CD-ROM productso that the user can view both the update and the original issues, andrun searches across the entire collection.

Optionally, initial location of additional information object 26 may bean application work area location on storage device 18, andcommunications component 36 may be pre-set to pass control via API 42 todatabase management module 30 which will do further processing tointegrate additional objects in accordance with the existing databasestructure 32 to provide a more complete level of integration permitting,for example, viewing of combined menus, nullification of obsoleteditems, and cross-linking of hypertext elements.

If a send object has been prepared and included in the object manifest,such as a send object containing user information entered during theinstall process, or subscription request information obtained from theuser, it is sent to server 22 to be stored and identified by product anduser ID for appropriate action in due course. Acknowledgment of receiptof the send object is noted by communications component 36 and passedback to the user if such provision is made in user interface 28.

Both the fetch and send operations are closed ended in the sense ofbeing operations that are pre-described in the original informationproduct and once triggered, can be completed without human interventionof any kind

To service the automated update facility running at the user'sworkstation, remote server 22 is set up to accept calls from valid userID's, and is loaded with new issue text and index files, in the form ofupdate information object 46, according to a publication schedule.

Example 2 Open Ended Fetch of a Supplementary News Magazine Object

Open-ended access to supplemental information objects not described inthe original information product can be obtained by providing in theoriginal product means to fetch a directory of added features. This canbe used, for example, by a news magazine publisher to provide specialnews features on an unplanned basis, or each weekly issue could bepackaged with a directory of additional features available. The userfirst specifies a fetch of the new directory, or receives it along witha fetched update they have specified from a user interface menu, andthen views the fetched additional features directory and initiates afetch of a selected additional item or items in a second informationobject transport operation, using an information object manifest builtfrom the new features directory.

The original, containing product news magazine CD-ROM user interface 28preferably has provision for importing and viewing any informationobjects listed on a completed fetch manifest and delivered by theinformation transport component 14 into the designated work areas.Alternatively, a standard information transport component 14 userinterface 34 can be used to provide this function in a less integratedform.

Example 3 Retail Catalog on CD-ROM with Merchandise Order Entry at theServer

Multimedia product catalogs with 800 ordering numbers are now availableon CD-ROM and also with pre-installed software packages on new computerhard disks. In this example, the multimedia (or text and graphic)product catalog is a read-only information product 17 which can befurnished with an information transport component 14 according to theinvention, to facilitate order placement from such electronic productcatalogs providing an easier order placing process than has heretoforebeen possible. Employing the inventive information transport component14, a catalog vendor can enable a customer to place the order directly,via modem, without requiring a voice call and ensuing verbal productidentification, by pointing and clicking a “Place Order” or “Mark forOrder” button on the user's computer screen. The order is transported toremote server 22 using the novel information transport component 14.Preferably a verification routine is included, requiring orderconfirmation with a user-supplied password, and possibly keying of thetotal amount to prevent unauthorized or inadvertent product ordering,for example by children.

Order fulfillment is effected by processing of the information in duecourse after receipt by the remote server 22 and any additionalinformation required centrally is collected during product setup andheld locally for transmission with an order. For example, setup cancapture the user's charge card information, shipping address, and thelike and create a header for an electronic order form.

When the user clicks the “Mark Order” button, procedures supplied withthe user interface 28, as modified through user interface API 40, addorder item identification information to an electronic order form. Whenthe user clicks the “Place Order” button, user interface 28 triggers atransport request to server 22, to include the order form as a sendinformation object 46. Transport of the send object, including the orderform, from the user's station to the server is executed employing anobject manifest 48, as described herein.

If not located at a vendor's or merchant's premises, server 22 canforward received electronic orders to the merchant for fulfillment, atappropriate intervals, via a vendor link 50.

This simple, low cost mechanism for automated order placement, cancomplement telephone ordering but lacks the credit-checking andinventory status capabilities that are frequently provided by phone.However, such a catalog application could allow the user to request thefetching of an inventory and price update object for use prior to thepreparation of an order.

Example 4 Merchandise Order Processing and Confirmation Retail Catalogon CD-ROM

A powerful electronic merchandising tool can be provided by providingthe user with a full-function order generating capability and employingtransporter 14 to transmit a user-created merchandise order,effortlessly and seamlessly, to a remote order-processing server. Tothis end, server 22 should be interfaced to the necessary merchantprocessing services for checking and reporting credit and inventorystatus.

An additional valuable option enables the system to apply pre-specifieduser instructions, previously obtained through user interface 28, todetermine whether out-of-stock items are to be dropped, back-ordered, orsubstituted in color or other aspect. This information can be added tothe electronic order form object, listed in object manifest 48 andbecome the subject of a further transport dialog between the user'sstation and server 22. In this manner a sophisticated purchasetransaction is completed in a substantially unattended manner (save fordeciding about back orders off-line), in as much as the customer doesnot have to maintain a phone conversation, while fully achieving thecapabilities of telephone order placement. A further user benefit can beobtained by the providing a permanent record of the transaction (astored electronic file) without user intervention. This not possiblewith telephone ordering.

This novel, automated, modem driven, order placement system effectivelyshields a merchant from having to deal with the problems of establishingcommunications with a mass of unknown end user computer systems, whileautomating the process and relieving the merchant of the costs oftelephone sales staff. This aspect of the invention is valuable inavoiding troublesome, support intensive, communications which aresubject to rapid technical change as new products are absorbed into themarketplace. In contrast, the merchant's special purpose vendor link 50to the server 22, can remain relatively stable, while the customerinterface at server 22, depending upon the sophistication anduniversality of the API's 40 and 42, and also upon any emergentcommunications standards, can be adapted to accommodate a range offuture products.

Example 5 Further Applications of the Invention: Locked InformationProducts

As discussed in the “BACKGROUND OF THE INVENTION” hereinabove, somevendors, for example Microsoft Corporation, distribute informationproducts in locked, inaccessible form, accompanied by (user-accessible)promotional information and demo versions. The prospective purchaserthen calls an 800 number to order the product and is given a code whichis entered to unlock the item for use. The inventive informationtransport component 14 and cooperative server component 22, can be usedto simplify this process, and eliminate the voice call.

The information transport component 14 is used to place the order and asa subsequent step concomitant with satisfaction of the merchantspurchase requirements (payment, etc) can, employing a suitable lineentry or entries in the object manifest 48, fetch the access code, as aninformation object 46, in the same way as an order acknowledgment orother information update. The user interface and data managementcomponents of the distribution CD, or original information product, canbe programmed automatically to use the code to unlock the product.

Employing the novel, digital, modem-enabled communications products ofthe invention, more sophisticated access codes than are suitable forverbalizing to a caller, can be used, and may include small programs ordecompression utilities (although these would better be stored in thelocked product), or customer-specific coding employing user-derivedinformation. Thus, as a safeguard against fraud, being equipped withspecific user or user product information, the access code can be a keyor product uniquely matched to the user's locked product copy.

Computer Software Updates: For distribution of updates to softwareproducts, the original distribution version of the software product canprovide registered users with an appropriate ID code and updateschedule. Should the revision be delayed, a revised schedule can befetched.

Tax or other governmental filings and exchanges: An example of thegenerality of the inventive information transport system for sending andfetching well-defined information objects of many kinds is in the filingof tax returns. A send information object can be created and manifestedto submit electronic tax filings to the IRS, as described above, forelectronic product order forms. A fetch object can be created to obtainupdated tax forms and the program logic relating to them, and to getinformation on new regulations. Analogous uses will be apparent to thoseskilled in the relevant arts of, for example, financial planning andportfolio management systems, to obtain current statistics, placeorders, and the like.

Packaging of Transporter with User Interface/Database Search SoftwareFacilities

In a modified embodiment, the inventive information transport component14 is integrated with a general purpose user interface/database search(UI/DB) software package and tools. Such packages and tools, sometimesreferred to as “authoring packages”, are now used to produce CD-ROM'sand similar information products. Thus a single UI/DB product maycontain the inventive information transport component 14, and besupplied to publishers to be used to develop a family or diversity ofinformation products, as a standard tool box.

A combination of the inventive information transporter product with suchUI/DB products could facilitate development of applications by allowingmuch of the work of integrating a containing product's user interface 28and database functions 30 and 32 (which could be controlled through theUI/DB product) with the inventive information transport component 14 tobe performed once, in advance, by a UI/DB software vendor's skilledspecialists, for use in a diverse range of products using that vendor'ssoftware. Such integrated offering would be advantageous to both thesoftware vendor (by enriching its offering) and to the software vendor'spublisher-customers by facilitating the desired function.

Electronic Product Distribution Service

In a valuable application of the novel electronic information transportproducts of the invention, remote server 22 can be operated to providean electronic data product distribution service for multiple containinginformation products 12, each equipped with an information transportcomponent 14, the whole facility providing a complete networkdistribution service, including network, technical and end-user support.Provision of such a distribution service is greatly facilitated by thenovel transporter 14, described herein, the use of which for each vendedproduct greatly simplifies the problems of handling updates to multipleproducts. However, such a novel service could also be operated withconventional software communications products by relying upon users ofeach to execute an appropriate sequence of menu selection and commandline instructions to obtain an update by modem via their ownpre-existing communications software. Similarly, While specialadvantages of seamless user adoption and integration into an originalproduct accrue from the use of the inventive transporter to distributeproduct updates, such a distribution service can be used with advantageto distribute any type of electronic information product.

For many publishers (and for providers of UI/DB authoring software) thetask of operating a publicly available server 22, and of supplyingassociated technical support to a wide base of customers using adiversity of communications products, even with the simplificationbenefits provided by the inventive transport product, is a taskrequiring specialized skills and staffing that a publisher, even oneexperienced in electronic publishing, will generally lack. Such aspecialist capability is intimidating to provide and difficult tocost-justify for the limited number of information products that onepublisher can supply.

By providing a new turnkey service or service bureau a specializing,skilled vendor would enable the publisher to avoid such burden. Aprovider of such a novel service can spread the costs of suchoperational activities and skilled staff across a large number ofpublishers and information products, achieving economies of scale andspecialization.

The inventive information transport products extend to softwareimplemented at server 22, or at one or more clients or satelliteservers, of a network served by server 22, to provide theserver-location functions of such an electronic product distributionservice. Such distribution software can be separately marketed topublishers or UI/DB vendors who wish to operate such a service.

Gatewayed, “Open” Server

Example 4, above, shows how information transporter 14, as well asserver 22 can remain simple yet provide a highly general and extensibleservice. In that example, server 22 provides the functionality of ageneral-purpose transaction gateway or interface to an external functionprocessor. In this particular case, the external function processorgatewayed by server 22 via vendor link 50, is the merchant's orderprocessing system, which receives the order, determines its disposition,and responds with order status information which is relayed back toserver 22 for return to the customer as a response object in accord withprotocols 38 and 44. The user need not be aware of such complexities,nor do the client transport components 14 of the inventive product needto be aware of, or provide information for remote routing via vendorlink 50. Only the server 22 needs this information, and server 22 needsonly to know that send objects with names that fall within a specifiedclass for a specified product ID, must be forwarded to a specifiedexternal processor, and that the corresponding responses from thatprocessor must be routed back to an originating client as responseobjects. Thus the inventive information transport component 14, byvirtue of its simplicity has general applicability and many uses, asdescribed herein and as will further be apparent to those skilled in theart.

In implementing an ordering service using the inventive informationtransport component 14, order and response objects are preferablyformatted by the containing information product 12 to be consistent withexisting or future electronic data interchange (EDI) standards whichdefine protocols and formats for data interchange between customers andvendors. The information transport component 14 and the server protocol44 provide the low-level EDI transport functions and are independent ofobject content defined by higher layers of the EDI protocol. Preferably,the server has added routing layer information to move objects to andfrom the external processor.

To provide a suitable EDI-compatible function, server 22 can beprogrammed with such higher layer EDI routing data for its exchangeswith the merchant's external processor. Employing such a gatewayedsystem, a single EDI network connection can be used to connect theserver 22 to a large number of different merchant processors anywhere inthe world, across wide area networks and links between same, for exampleInternet.

This concept of an “open” server, providing a gatewayed pathway forinformation objects to travel between a wide base of users and one ormore remote vendors or other object sources is greatly facilitated, orenabled, by employment of the inventive transporter 14 which effectivelyprovides a protocol translation function enabling a simple informationtransport service to be offered which is easy and economical to use,both for the end user and the vendor or information supplier. Such atransport service compares favorably, for its intended informationtransport purposes with broader function and more complex of full onlineservices, such as COMPUSERVE (trademark), and the like, describedhereinabove.

Further Embodiments with Broadcast, Subscription Delivery and On-DemandCapabilities

Receipt of broadcast data: As an alternative to modem-based wireline orwireless calling to a server and requesting data objects, theinformation transporter system of this invention can be beneficiallyemployed in a broadcast information distribution system wherein datainformation objects are contained within a broadcast data stream withrecipient communications devices tuned to identify and receive from thebroadcast specific data elements to which they are entitled. On theInternet, such broadcasting to a selected group of recipients is called“multicasting.”

Broadcasting can be airwave broadcasting via satellite, FM, or TVsubchannels in the manner, for example, used by Mainstream Data Ltd. forthe broadcast of news wires. Alternatively, the broadcast data streammay be cable or line transmitted, for example, over cable televisionsystems. Minor extensions to API's 40 and 42 could accommodate such afacility. A modified setup function could alert a user's receivingcommunications device to watch for receipt of data objects identified asrelating to the original or containing information product, and tocapture and hold identified objects in temporary storage. A scheduletransport function can then be set to fetch the received data objectsfrom temporary storage and prepare them for use.

Subscription delivery: Although the invention has been described asbeing particularly applicable to the solution of problems arising indistributing updates of original or previously purchased or deliveredelectronic information products, those skilled in the art willappreciate that, many of the benefits of the invention can be obtained,without any initial information content being delivered to the user,with the original product. The user could simply receive the informationtransporter 14 and all product information could be receivedsubsequently, after installing the information transporter 14, in theform of fetch objects transmitted from a remote server or other suitablesource. For example, a newsletter service could provide a disk with thetransporter and a user interface, but with no initial informationcontent. As the transporter 14, operating at the user stations,automatically fetches new issues according to the newsletter schedule,the information is, in effect, pushed down a channel from thedistribution server for delivery to the base of subscribing users.

Information-on-demand services: In another embodiment, providing aninformation product on demand service, vendors can freely distribute anovel electronic marketing product comprising a transporter on diskette,along with a simple user interface and a catalog of information productitems available from the vendor, without including the productsthemselves. Such an electronic marketing product could be distributedthrough the mail, as a magazine insert giveaway, on or through any othersuitable marketing medium. The transporter could be activated at anytime by the user to call in and fetch a cataloged product, as well as acurrent catalog, possibly after sending a credit card order form, or theproduct price could be paid to the vendor by obtaining the product froma 900 number providing vendor reimbursement from the telephone network.

Open Architecture Online Service Access

In a further aspect, the invention provides an information transportcomponent 14 that functions as universal or generic client interfacesoftware, enabling a user client to work with any one or more of manyonline server-based information distribution services.

Many online information distribution services used to disseminateelectronic publications comprise intelligent user interfaces whichemploy a client component running on a customer's personal computer (PC)to communicate with a central server facility operated by the onlineservice, by means of a proprietary protocol. The client interfacepackages are proprietary to a particular online service.

Prospective publishers wishing to offer electronic products online,contract with online service providers to enable customers to use theonline service's client software to access the publisher's material andrelated online communications services (bulletin boards, etc.) on theservices' servers. The publisher is limited to using the presentationfacilities provided by the user interface in the online service's clientsoftware. This limitation impedes migration of publisher offerings andmakes it difficult for either a customer or a publisher to swinginformation transport component 14 access from one service provider toanother because each service requires its own software package.

Third party interface developers cannot contribute to such onlineinterfaces for a publisher without the cooperation of the online serviceprovider which may be difficult or impossible to obtain. Accordingly,only limited user interfaces with moderate sophistication and varietycan be offered.

Accordingly in another aspect, to provide open architecture onlineservice communication, the inventive information transport component 14can be embodied as a flexible client interface which can be actuated tooperate with any one of a number of online services by providing ageneric client interface foundation API (application program interface)combined with a set of translators and protocol drivers capable ofcommunicating the user's functional requests to any one of a set ofonline services, using their corresponding proprietary protocols.

In this aspect the invention permits publishers to develop highlysophisticated and individualized user interfaces independently of thelimitations of the online service providers' capabilities. Such enhanceduser interfaces are attractive to publishers seeking differentiation oftheir products by providing an appealing individualized interface with asignature look and feel. In contrast, online service providers seekingto economically carry content from many publishers provide genericinterfaces acceptable to all.

By incorporating operational translators for a number of online serviceprotocols, which translators fully adhere to the detailed specificationsof each protocol, a multi-service capability can be provided.

Online services generally provide similar types of services with nearlystandard functions and similar user interfaces. Major service typesinclude bulletin board, chat, electronic mail, document browsing, anddatabase search. Use of creative typography, layout, graphics, and otherartistic elements to offer the presentation quality and variety typicalof print media is desired by publishers using this medium.

The invention facilitates this end by providing open developmentplatforms for development of advanced interfaces while shieldingdevelopers from the complex details of communication with an onlineserver. The shielding is accomplished by providing an API which supportscommunications service requests at a simple functional request level.

Referring to FIG. 3, multiple targeted online services 80, can beaccessed by a client interface 82 comprising any of multiple graphicaluser interfaces 84 driving a generic API 86 which works with plug-intranslator/communicator modules 88 which are provided to communicate oneto each targeted online service 80. Modules 88 mimic the onlineservice's protocols, so as to be essentially indistinguishable from theproprietary interfaces normally used. A communications manager 90receives input from API 86 and outputs through protocol mapper 92 whichselects the appropriate protocol.

In this embodiment, for use with full-function online services, thefunctions of API 86 and protocol 88 are extended to support extended,open-ended interactive sessions and the more varied client-serverinteraction needs of session-oriented interactive online applicationssuch as bulletin board posting and browsing, online chat, electronicmail, database and menu browsing, and database search.

Similarly, in the aspect shown in FIG. 3, the invention can be providedwith the same kind of additional flexibility with regard to the user'sconnection to server 22 as the invention can provide for more basicfetch and send functions. While the inventive client server protocol 38and 44 is particularly suited to the functions described, other existingor future services and corresponding protocols could be used, ifnecessary with adaptation, to provide workable services for use inconjunction with transport component 14. Such use may requiremodification of communications module 36 and protocol 38 by the additionof a protocol mapper 92 and appropriate server protocol plug-in 88 tocommunicate to an alternative server.

In either case, such added flexibility in use of the inventive productincreases a publisher's choices in selecting server and networkfacilities through which to distribute information products, and enablesthe publisher to offer fully customized user interfaces for use withmultiple, or any one of multiple server and network services which donot provide for such customization. In this embodiment of the inventivetransport component, a containing product can offer a unique custominterface and provide for access to additional information products fromsuch varied source facilities as the Internet, full function onlineservices, emerging groupware network services, conventional bulletinboard systems, and future network services using wireless or cabletelevision technology.

While the invention can provide a flexible, generic API, in somecircumstances, an existing third-party API designed for use with asingle specific online service can be combined with an embeddedtransporter and server protocol mapper to allow products designed to usethe third-party API to employ any of multiple servers for distribution,avoiding commercial distribution restraints associated with that API,for example use of a particular server.

The inventive protocol mapper 92 can insulate a containing informationproduct from the variations among such services, and can allow a singlesuch information product to be transported through a variety of suchservices, and to later be moved to other such services by simplyselecting an alternative protocol mapper. Multiple such protocol mapperscan be packaged within a given information product to permitalternatives to be selected by the end-user from a list. Thus theinvention further permits information products and related UI/DBauthoring tools to be service-independent and neutral.

FIG. 4 provides an overview of the use of the inventive client interfaceaccessing multiple publications via multiple remote online services, aswell as multiple locally mounted data sources and storing additionalretrieved data locally.

Enhancements can enable a publisher's service to provide integrated,seamless access to content distributed over several different onlineservices; to seamlessly combine access to both online and localCD-ROM-based content; and to coexist with and share resources with otherpublishers' services on the user's PC.

In summary, the invention provides, in this aspect, a simple,easy-to-use multi-protocol capability that enables an electronicinformation object to be transported from a publisher to a wide base ofusers by any one of a number of online services, without sacrificingindividual product identity.

Recursive Updating of the Transporter

Another application of the inventive information transport product, ortransporter, is a recursive use to update itself, in the same mannerthat the transporter can update a containing information product. Thismethod can be useful in a variety of ways, including to upgrade thetransporter by the addition of new protocol components, new compressiontechniques, or new network access methods.

An important class of such self-updates is to provide added flexibilityin specifying network access procedures. For example, the user setuproutine could be extended into a two stage process. In a first stage,each user's transporter calls in to a common pre-set phone number, inorder to fetch a second phone number selected according to the user'sparticular product, location, or some other parameter. The second phonenumber, or other address, can then placed in the setup as an update, tobe used in subsequent transport operations.

This two-stage method can provide efficient use of a single pre-settoll-free 800 number for an initial call from any number of differentproducts, which initial call yields a second number corresponding to aspecific Product ID, which number is used for subsequent calls.

In an advantageous embodiment, the second number is not toll free andmay include vendor charges, in the manner of a 900 number. Thisarrangement enables a system in which users do not pay for initial setupcalls (and any failed connections which might result from initial setupproblems), but do pay long-distance toll charges, and per call vendorfees if the publisher so desires, for subsequent product informationtransport from the second number. This two-number process can be carriedout without requiring any phone number entry or selection by the user.Additionally, the second number can readily be changed whenever desiredby the publisher, even after product discs have been shipped.

User's Station

References herein to a user's station, workstation, computer or terminalwill be understood to embrace any “information appliance” or intelligentdevice having the basic computer-like functions of programmed logic,storage and presentation, or having the ability to support an operatingsystem for managing user input-output with a processor, includingintelligent cable television controllers, video game players,information kiosks, wired and wireless personal communicators, and evensystem controllers such as automotive computers.

Benefits Provided by the Invention

Employing the novel information transport component 14 interacting withremote server 22 through communications protocols 38 and 44, theinvention enables the following advantageous objectives and otherbenefits to be achieved:

-   -   i) simple and easy execution of one or more fetch or send        transactions to or from a remote server, by an ordinary,        unskilled user with no human interaction at either end being        necessary after initiation;    -   ii) automated transport of predefined information objects        between client and server in a closed-ended fashion, without        burdening a client-based user with complex routing logic; and    -   iii) creation of an economic, easy-to-use, function-specific,        self-contained information transport component 14 software        module suitable for mass distribution in a containing        information product.

The preferred use of an object manifest in a transport control mechanismwhich includes transporting the object manifest between client user andserver, and referencing the object manifest by user fetch-send protocol38 and server fetch-send protocol 44 facilitates achievement of thefollowing additional objectives:

-   -   iv) simple, tight-knit control of the communication process and        of error handling; and    -   v) creation of a transport control mechanism, and thence of an        information transport component 14, which operates smoothly and        transparently to the user and independently of the information        object content or of the nature of the application.

The invention thus provides an information transport software componentwhich can be employed to transport a wide variety of data objects orapplications and can be easily incorporated in many differentinformation products to provide multiple novel containing informationproducts 12 with built-in automated updatability or upgradabilityexecutable at an appropriate time by simple, user-menu selection orautomatically.

Further Benefits

In addition to the benefits of a powerful and efficient informationtransport method, use of a standard, formalized transporter, its API,and client-server protocol, pursuant to the teachings of the inventiondisclosed herein, can provide any or all of the following significantbenefits to users, information product vendors, application vendors,service providers, tool vendors or others:

-   -   vi) use of a standardized facility to perform a well-defined        function in a known way (with available implementations for a        varied and expanding set of hardware and software platforms);    -   vii) reliance on a standardized facility that can be extensively        tested and proven reliable across a wide variety of equipment        and conditions;    -   viii) reduced need for information product developers (and        users, and user interface/database search software vendors) to        know and understand the complexities (and rapid evolution) of        data communications;    -   ix) ability to build a single functional interface that can        smoothly employ a dynamically expanding variety of        communications facilities and technologies;    -   x) ability to obtain operations and user support services        relating to the difficult task of managing a server and its        communications with large numbers of end-users;    -   xi) user-recognition of the novel information transport facility        across a range of unrelated products, establishing a positive        brand cachet benefiting users and vendors alike;    -   xii) ability to package the transporter facility with other        tools, such as a UI (user interface) and database search        capability to extend the value of those tools economically and        with the ability to gain the benefits described above; and    -   xiii) control of communications costs and failures by        elimination of human intervention, with its attendant        time-consuming delays and errors, from the period during which        the user's station is connected in real time communication with        remote server 22.

Stated succinctly, by having the novel information transport componentrely entirely on a containing information product for all user interfaceand information presentation functions, there need be no restrictions onthe creativity of the containing product imposed by the needs of a thirdparty communications product. Thus the containing information productcan present transport functions with any desired look and feel.

Another advantage of the information transport system of the inventionis the avoidance of difficult or complex navigation tasks, and the useof simple direct dial communications which are suitable for sessionsthat are short and infrequent. The inventive information transportproducts described herein are consistent with or readily adaptable tothe needs of many publishers of a diversity of materials, which needsare commonly centered on discrete products and content.

A further advantage of the invention, from the point of view ofpublishers, is that because the call is customer initiated, the customerpays transport costs (telephone line charges), simplifying costing forthe publisher who avoids having to figure shipment or othertransportation costs before sale and build these costs into the price ofthe product or update.

The inventive approach to mass distribution of electronic informationproducts described herein can also provide advantages in high-valueenvironments such as those of Counterpoint Publishing's Federal Registerproducts cited hereinabove, providing a more seamless integration of thefetching of updates received via modem (and selected and extracted bythe user from the “Daily Federal Register”) with the original product onCD-ROM, the “CD Federal Register”. Product installation can besimplified, and a separate user invocation of, and interface to, ageneral-purpose communications package can be avoided. In addition, byemploying the user's pre-existing modem and avoiding need for a generalpurpose communications product license, significant cost savings can beobtained.

The better to comprehend its possible applications and enhancements,embodiments of the invention can be grouped in four levels, as afollows.

Level Zero: A novel basic transport function embeddable in any of arange of electronic information products to provide economicalunattended updates.

Level One Basic: Transporter 14 incorporating API's 40 and 42 adds apowerful new capability to be used with an electronic informationproduct's custom user interface and, optionally enhanced with a databasemanagement facility for seamless integration of an update with anoriginal product.

Other options can integrate with relevant third-party packages such asauthoring packages.

Level One (Server enhanced): Adds server operation and user supportfeatures enabling publishers to outsource tasks which may be difficultor unfamiliar to them.

Level Two: Adds optional translation or use of alternative serverprotocols enabling an embeddable transporter product to work with manydifferent servers or services including, for example, standard BBS's,Internet servers, and special transport services such as those offeredor proposed by communications providers such as AT&T, MCI, Compuserve,America Online and cable television systems.

Level Three: Adds a full online service user interface API withcorrespondingly enhanced client-server protocols to provide forfull-function online service sessions with user interface control,ability to work with a range of online services, providing a publisherwith flexibility in their use of existing and emerging services.

These four levels of the invention are illustrated schematically inFIGS. 7-11. Referring to FIG. 7, depicting a basic Level 0 embodiment,user 100 employs generic onscreen interface 110 to initiate an updaterequest 112 from a remote source (not shown), for an update object 46.After initiation, for example by clicking on a button in genericinterface 110, communication with the remote server and retrieval of theupdate object 46 can proceed automatically, as described herein.Alternatively, although not shown, similar means could supportsubmission of a send object to the remote server, both at the basiclevel 0 and in the cases of Levels 1-3.

In the Level 1 embodiment shown in FIG. 8, incorporation of APIs 40 and42 in or with transporter 14 enables the containing information product12's user interface 114 to be supplemented with object transportationfunctions. Also shown is a received update object 46 seamlesslyintegrated with information product 12 using a database managementmodule (not shown) as described in the parent application.

When the Level 1 embodiment is enhanced with a database managementmodule or with an authoring package a particularly valuable embodimentresults, which may be described as a UI/DB-package-enhanced Level 1. Inmany possible applications, product 12 may not be created by originalprogramming from scratch, but may be created by employing a standardsoftware package which is then customized to integrate the desiredpublisher's information content with a standard software package ortoolkit that provides the UI/DB functions. Such a UI/DB package ortoolkit can use APIs 40 and 42 to provide a point of linkage to thetransporter 14.

A programmer, developer or other software provider is thus by such anenhanced Level 1 embodiment to offer a software package which can easilybe utilized by many different publishers to add whatever content theydesire, and gain the advantages of automated, or managed informationobject transport, as described herein, while avoiding any need for thepublisher to address the tedious and perhaps difficult mechanics of thetransport operation.

The software provider can use the inventive transporter 14 as anoptional element, or include it as part of his enabling product, thusoffering added value to the publisher. In doing so the software providercan, if desired, set up a standard or readily customizable set of UI/DBelements to support the desired transporter functions, and provide allcorresponding interfaces to APIs 40 and 42, thus relieving the publisherof the need directly to interface to the transporter via its APIs. Suchan approach of integrating the inventive transporter with a more generalUI/DB authoring package can also be used to include the inventivetransporter component into a more broadly functional offering topublishers for the more advanced embodiments of Levels 2 and 3. It willbe apparent that if a third party authoring package offers an API orsystem developer's interface for use with its product, the integrationof the transporter with such package may be best accomplished bycreating a special and novel interface module which links between thatexisting UI/DB package's API and the transporter APIs 40 and 42. Such anAPI interface module comprises an element of the invention.

The server-enhanced Level 1 embodiment depicted schematically in FIG. 9shows how operation of a server 22 and technical support functions canbe off-loaded by an electronic publisher 116 to a server operator 118.Electronic publisher 116 can distribute an information product 12, whichmay be complete with content, or may be merely an enabling shell,directly to users by whatever means is appropriate includingdistribution on physical media and electronic downloading. Updates arethen furnished to server operator 118 to complete distribution ofupdates to appropriate users. As will be apparent, updates may embraceessentially any desired information or content, including originalcontent intended to fill a previously distributed shell.

As shown, transporter 14 can be contained in each of a number ofinformation products 12 distributed by one or more publishers to one ormore sets of customers. Multiple information products 12 can be updatedfrom a single server 22 or a server 22 may be dedicated to eachindividual product 12. The electronic publisher is thus relieved of theexpense of replicating and distributing updates, or of the technicalchallenges of maintaining their own distribution server 22.

If desired, integration between a fetched object and originalinformation product content can be effected by a separable contentintegration module for seamless viewing or processing by the user ofcombined local and remote content. The integration module can comprisethe user interface and database integration tools, and may or may notcontain the transporter 14. Such an integration module, with or withoutthe transporter, may, subject to customization to meet the purposes ofthe invention, be obtainable from third parties.

The Level 2 embodiment depicted in FIG. 10 illustrates how the inventionenables great communications flexibility to be easily included intotheir products by publishers or producers and, in turn, put in the handsof even novice users simply by equipping transporter 14 with multipleprotocols enabling the user automatically to access any one of multipleservers 22 or other remote communications facilities (by includingmultiple protocol plug-ins, as illustrated in FIGS. 3 and 4 anddescribed in the parent application page 78, line 12). Illustrated, byway of example, are an Internet server 22, or Internetpoint-of-presence, through which all or any server on the Internet maybe accessed; a BBS server 22, or “bulletin board” server for access tolow-cost direct-dial servers; and a third route to any other desiredremote communications-equipped server, which may include commercialonline services, is also shown. By channeling communications and remotedata retrieval to the user via the containing information product 12, aseamless presentation through the information product 12's distinctiveuser interface 114 can be made. For example, a stock management productcould access one remote server to update prices of the users stocks anda bulletin board to obtain current news items of the company whose stockhas been updated.

In another application of this Level 2 embodiment depicted in FIG. 11,transporter 14 includes multiple client-server protocols enabling it toaccess any one of several online servers I, J and K. This embodimentenables a publisher to distribute product and permit the user to updateor supplement it via whichever online service they happen to use, orsubscribe to, thereby enabling a publisher to economize on the serverfunction by using an established online service, yet reach the widestpossible electronic consumer base by reaching users through any one ofmultiple services, e.g. CompuServe, America Online, Prodigy, MicrosoftNetwork or other proprietary online service, or Internet accessprovider, each of which may have limited accessibility determined bymarket scope, geography or technology or the like.

The inventive transporter enables the publisher to accomplish this witha single, uniform interface to APIs 40 and 42, and thus without need toimplement costly program interfaces specific to each online service. Asdescribed in the parent application, a preferred embodiment of theprotocol plug-in maps the APIs 40 and 42 to any suitable pre-existingAPI available for use with a target online service, such as is offeredby CompuServe for connection to its online service, or for use with anInternet server. (Alternatively, a converse translation could beeffected: APIs 40 and 42 could be overlaid by a layer that simulates apre-existing protocol used by a containing product 12 to communicatewith a single online service I, thus allowing it to be retargeted toother online services J or K or other servers 22, without significantprogram change to the containing product.)

The Level 3 embodiment, as described in the parent application, can alsobe depicted using FIGS. 10 and 11, where in this case the connectionprotocols are enhanced to support full, continuing online sessionfunctions such as browsing, search, and chat.

Level 0 enables a user to retrieve remote information objects such asinformation product content or software updates, or send in informationobjects such as product registrations, or orders or inquiries, in anautomatic, unattended manner after initiating the communications processwith, for example, a single mouse click.

Level 1, by providing suitable API functionality, enables automatedobject retrieval (and send) functions to be integrated into theinformation product's own interface, a significant user and marketingadvantage. Level 1, UI/DB-Package-Enhanced, integrates with authoringpackages to simplify the information product producer's task evenfurther. Level 1, Server Enhanced, by including server functionality,provides a complete service for a publisher.

Level 2 enables information objects to be fetched or retrieved, or to befurnished from pre-existing commercial services, with which the user mayalready have established communication channels, for example bysubscription and enables a publisher to reach most or many users via asmall number of pre-existing commercial online services. In addition,Level 2 enables a user to integrate local content, available from theuser's local physical media, hard drive or optical disk for example, orlocally created content with online content drawn from online sources orthe Internet.

Level 3 enhancements of transporter 14, and especially of APIs 40 and 42can permit tight-knit, seamless integration of appropriate content infully online modes, giving the user an open-ended feeling of continuitybetween their own local resources and retrieved remote content. Thisfacility is of particular value for sophisticated multimediaapplications which may require content from multiple sources to beassembled into a coherent work such as a television commercial, atraining video or “mini-movie”, using moving video frames, text content.voice, photographs, special effects and so on, for highly interactiveprocesses such as extended, free-flowing browsing and searching ofrelatively unbounded network content, and where dynamic contributions orinteractions among multiple participants are to be accommodated, as inconferencing or real-time gaming applications involving interactionsbetween multiple network users.

Equivalent Networks and Interface Devices

The invention described in the parent application addresses, inter alia,the problems of moving digital information objects across a telephonenetwork between a remote source and a disparate body of users andprovides a transporter which simplifies and automates transport enablingeven novice users to exchange pre-specified objects with a remote sourcevia the telephone network using modems or equivalents. It will beapparent to those skilled in the art that, unlike a local area network(“LAN”), a telephone network, the phone numbers of which may be regardedas network node addresses, nevertheless lacks a distributed filemanagement system for simple transport of files between nodes. Functionssuch as verification of safe receipt of information objects are readilyeffected on a local area network, for example by executing a directorylisting of a remote node address, and much more sophisticated transportmanagement capabilities can and are readily provided by networkoperating systems, network utilities, network management applicationsand so on.

A fully functional distributed file management service, such as isprovided by a local area network (sometimes called a distributed I/Oservice, “I/O being an abbreviation for “input/output”) permits remotefiles to be manipulated and accessed via the user station's operatingsystem's normal file I/O read/write and move/copy commands, much as ifthe file were on a locally attached device (once appropriate accesspermissions have been enabled), without the complicating need forspecial, supplementary remote file access protocols such as FileTransfer Protocol (FTP). As explained in the parent application, LANsimpose burdens including significant initial costs and setuprequirements, homogeneity and complexity at the nodes, logindifficulties and so on, which problems are not shared by the ubiquitoustelephone network to which anyone may successfully connect with adiversity of computer and modem or equivalent equipment.

It will be apparent that the benefits of the invention are obtainablewhen using other mass-market communications networks equivalent to atraditional telephone network which equivalent networks lack basic filemanagement capabilities. Some such equivalent networks, which may or maynot include file management capabilities, and which may be deployed overtelephone network hardware, or interface therewith, include ISDN, ATMand ASDL as well as off-air services such as cellular or CPCD and aswell as, cable television networks for which computer connectivity isemerging in 1996 (as foreshadowed in the parent application). Suchvarious networks will usually require their own interface device, forexample an ISDN board or a cable modem, which for the purposes of thepresent invention, and to the extent that they are deployed on networkswith a lack of distributed file management services (or where suchservices cannot be relied upon to be available to any given userwhenever needed), will be equivalents of ordinary telephone modems. TheInternet as well as proprietary online services or other wide area datanetworks, especially public networks such as those using the X.25standard (as referenced in the parent application) also generally lackdistributed file management services. References herein to “directdial-up communication” and “telephone network” are intended to includesuch equivalent networks lacking distributed file management services,including the Internet, and references to a “modem” include suchequivalent network interface devices.

Products with Multipath Hybrid Access to a Remote Source

The invention can provide an information product with multipath hybridaccess to a remote source, enabling a user of the product to receiveupdates from, or otherwise communicate with a remote source. Pursuant tosuch a preferred embodiment, an electronic publisher, or other vendor,can combine, on a consistent basis in a single product, automated onlineaccess to the Internet, (or other data network with or without filemanagement capabilities) with dial-up access to enable a user to connectwith the publisher's server via whichever online service the useralready employs for Internet access or else via direct dial-up access tothe publisher's server, in the event that the user is not a subscriberto one of the online services for which a protocol is provided. Theaccess path can either be user-selected or may be automaticallysoftware-selected according to what installed modules are found on theuser's computer.

This embodiment is valuable for publishers desiring to reach a massmarket of computer users with a product that is readily updated in themost practical way. As at early 1996, in spite of the immense publicityreceived by the Internet, the majority of modem-equipped computer usersdo not have Internet access, nor do a large percentage use any otheronline service, except where the context indicates that the specific,ordinary meaning is intended. This is particularly true of home andsmall business computer users, who constitute a desirable market formany publishers.

Internet Applications

Internet access is relatively complex for an inexperienced computer userto set up, and usually requires commitment to a monthly subscription,yet once set up it is easy to use. The multipath hybrid accessembodiment of the invention has the advantage of enabling those userswho have Internet access to enjoy the functionality, speed and economyof a network path via the Internet, while other users, a vast market,can simply use dial-up access via the telephone network: they are notrequired to go to the trouble and expense of establishing an Internet oronline service capability. Some users may employ multipath accesscapabilities to use different access paths according to circumstance,for example, using a network access path from the home or office anddirect dial-up on the road where their proprietary online service, orother network access route may not be available.

Since the Internet is not expected to reach the majority of such otherusers for some years this embodiment is particularly advantageous forpublishers desiring to reach a mass market. Products that automatecommunications via an online service yet omit dial-up capabilities willexclude a large number of prospective customers. Technically, no specialeffort need be made to provide Internet access to users who do not havethe capability: it is simply used if present on the user's computer.However, the addition of a facility to set-up a new Internet or onlineservice subscriptions in a further expanded embodiment of the inventionwill be valuable to some users. Components for such new-user set-up arecommercially available for example from Internet software and servicevendors, and can be combined with suitable elements of the inventivetransporter component to give the user added options.

Although at the date of this application the Internet is such a dominantworld-wide communications force it is hard to contemplate alternativesnetworks, they may arise, and indeed local organizational equivalentsembodying some of the advantages of the Internet's standardization andhypertext capabilities are emerging and have been dubbed “intranets”.Equally, comparable or competitive wide area networks based onsubstantial new or existing infrastructure may emerge. Cable televisionnetworks might provide such an infrastructure base. In most cases,relevant aspects of the invention, as described herein in connectionwith the Internet will also be applicable to such alternative networksand intranets, to an extent that will be apparent to those skilled inthe art. As described above under the heading “Equivalent Networks”,like telephone-like switched point-to-point networks, unlike local areanetworks supported by a homogenous network operating system maintaininga shell at every node, more heterogeneous data networks such asintranets and the Internet do not generally support and provide fulldistributed file management systems enabling digitized files to bemanipulated in the same way as local files, although they generallyprovide for more limited services using protocols such as FTP or HTTP(hypertext transport protocol) which permit files to be copied from onenode to another with one or a few simple command line instructions.However, block transfer, for example to read one or more records from adatabase file, are either not, or not readily, accomplished. Nor can aremote program be executed.

Referring to their Internet origins and choosing to characterize them byimportant features of the World Wide Web (though other features might beused) the intranets and Internet-like networks described in thepreceding paragraph can be termed webbed data networks and are notablefor having multiple remote data servers supporting hyperlinked dataresources. Such webbed data networks achieve much of their utility fromemploying a standardized object preparation language, e.g., HTML, and astandardized file transfer or access protocol for platform-independenttransport and utilization of objects on the network.

Unless a different meaning is clearly required by the context, the term“web” is used herein to connote an array of hyperlinked informationobjects stored at one or many locations on a network.

Transporting Information Objects to and from Web Browsers

As described in the parent application, the inventive transportercomponent can be advantageously used to facilitate transport ofinformation objects across the Internet to and from containinginformation products 12, by automating access to the Internet and to apredetermined Internet site or resource. It can also be used fortransport across other network facilities, including direct-dial, andmany different user interfaces and content formats can be accommodated.It will be apparent from that disclosure that one such particularlyuseful embodiment of the containing information product 12 is that of aweb browser, as a UI/DB package which can incorporate transportcomponent 14 to provide an alternative, dial-up route of access toInternet servers that also support dial-up access via a telephone orequivalent network, or whenever use of the transporter's short-burstmode of closed-loop communication session is desirable. Similarly, suchaccess can be provided indirectly via a separate dial-up server whichcontains, or has access to, the content which is also accessible via aWeb server, or equivalent content.

Some known web browsers are discussed in Rick Ayre et al., “WebBrowsers”, PC Magazine, Vol. 14, No. 3, (Feb. 7, 1995) pages 173 et seq.As reported at page 175, column 1, web browsers can be embodied asoperating system components, for example OS/2 Warp (trademark, IBM) andMicrosoft's Windows 95 (trademark). As operating system software expandsand assimilates what were once free-standing, or separately marketedsoftware utilities, for example, memory managers, disk compressionutilities and backup programs, distinctions between what is operatingsystem software, or a utility or small application, become morecommercial or market-based than technical. Similarly, communicationsservices provided by Web browsers (such as HTTP protocol access) andother similar Internet tools (such as for FTP protocol access) couldalso be useful as software facilities on which to build transporterprotocol plug-ins, and it will be apparent that use of any suchavailable software components is contemplated by the invention, forexample, as comprehended in the discussion of protocol plug-ins in theparent application.

World Wide Web

Internet sites using the World Wide Web, “Web sites”, present theirresources via what are called Web pages, including top level pagescalled home pages and a linked network of other Web pages. Web pages maybe accessed and viewed with a Web browser program which providesstandard graphical user interface and data presentation functions toapply format controls coded into the Web page using a standard format toenable a visitor to the site to browse the site's resources via textualand graphic information, drop-down contents and catalog lists and viasearch windows with varying degrees of functionality.

Keys to the explosive growth of “the Web” are the use of standardizedcommunications protocols (“HTTP”, hypertext transport protocol) and datacontent and formatting coding language (e.g. hypertext markup language“HTML”) to effect real time transfer of interactive images (Web pagesand related content or services) across the Internet, using digitalpacket addressing. Sponsors or suppliers of Web material can use theirWeb pages as an interface to provide substantially any desired content.

In early 1996, today's format is HTML which is a currently popularembodiment of Standard Generalized Markup Language (SGML), a complexstandard, adherence to which provides the widespread readability ofInternet documents. HTML provides a format to describe the design of adocument and its connection to other documents accessible via theInternet, using hypertext links, or “hyperlinks”. Alternative contentformats such as Adobe's ACROBAT (trademark) provide similar formattingfor use with a suitably augmented browser, and other such formats mayemerge and evolve. Adobe's ACROBAT is an example of an authoring systemor application which creates information objects that are integratedwith their own display or utilization, applets (mini-applications) ortools, for platform-independent viewing or playing of the objects.

Typically, Web pages contain both internal hyperlinks to site featuresand external hyperlinks to other sites and they may also permitactivation or downloading of sound, multimedia or other moresophisticated content. Such hypertext links, or hyperlinks, provideimmediate initiation of a connection to an information resource forretrieval of an image, in response to a mouse click or two. Hypertextlinks use uniform resource locators known by the acronym “URL” to findresources on the Internet. The URL identifies the location of a file onan Internet server by a server address such as http://www.uspto.gov anda more or less extended directory path to a filename for a specific pageor tag within a page, if it is a Web site, or other data source.

Many thousands of commercial organizations use the Web for publishing,for customer service, for distributing product information via catalogsand the like, and for online sales. Content varies from a few simpletext paragraphs to large and complex data suites providing multimediapresentations, games or other entertainments with audio, video andanimation. New uses of the Web and methods of doing business arecontinually being invented.

A Web browser is an application running at the user's station which canaccess search engines, find and retrieve Web pages using URLs, andassemble the retrieved elements of text, graphics, sound and video, ifpresent, into a coherent printable document or playable presentation.Typically, a Web browser also provides a variety of tools to make “hotlists” of the user's preferred sites, to effect various file andconnection management functions, and so on.

Some drawbacks of the Web are that conventional Web access reaches onlya small proportion of households with personal computers and modems, (a1995 estimate is that only about 21 percent of 27 million householdswith personal computers had Internet access); that such access isgenerally available only by continuing subscription through an accessprovider service by paying a minimum monthly fee; that connection timecan be expensive; and that Internet access is subject to congestion andinterruptions, or loss of connection. For a commercial content providerdesiring to reach a mass market, these are important limitations.

Information Object Distribution System for Webbed Networks

To overcome these and other problems, the invention provides aninformation object distribution system for webbed networks, such as thenetworks described above, which system comprises:

-   -   a) a web site server at a web site on the network and supporting        hyperlinked information objects accessible to network users;    -   b) a web package server having an open-ended connection to a        telephone network for data exchange with desiring ones of said        network users directly via said telephone network and supporting        one or more web packages comprising selected ones or sets of        interrelated ones of said hyperlinked objects whereby said        desiring network users can obtain said selected hyperlinked        objects by direct dial-up connection to said web package server;    -   c) at least one web browser at least one of said user stations        to retrieve and view information objects maintained locally or        at said web sites on the network, said web browser being capable        of following hyperlinks between objects locally or on the        network; and    -   d) also at said one user station an information object        transporter for automated retrieval of one or more of said        selected information objects from said web package server by        direct telephone connection, said transporter being operable in        unattended mode after initiation to retrieve one or more        pre-specified objects from said web package server to said user;    -   wherein link rationalization is provided to enable appropriate        hyperlinks to be followed to retrieved information objects        stored at said one user station;    -   whereby a user at said at least one user station can choose to        retrieve one or more of said selected information objects either        via said browser and said webbed network or via said transporter        and said telephone network, and utilize said retrieved selected        information object at said user station.

Offline Browser

In this aspect, the invention also provides a computer-implementedoffline browser system for offline browsing of locally stored Web pages,which offline browser system is suitable for distribution to a massmarket of users, (or to a small group) and for operation at a localcomputer station, and which comprises:

-   -   a) local content elements for at least one local Web page, said        content elements being intended for storage at said local        station;    -   b) an offline browser to access and present said content        elements via said local Web page; and    -   c) a transporter, being an information transporter component, as        described herein, initiatable from said local Web page,        automatically to effect a dial-up connection, or its equivalent,        to a desired remote information source and retrieve at least one        preselected or pre-specified new content element to update or        augment said local Web page;    -   whereby said offline browser can be utilized to access said new        content elements via said local Web page and provides user        interface function for such new content access. Preferably, the        browser also includes conventional online browsing capabilities.

Such offline browsing in which hyperlinks may be actively pursued, maybe termed “active” offline browsing to distinguish from mere passiveviewing of the content, or web pages, wherein hyperlinks are eithernon-responsive, or yield errors.

At least some, if not all, of the local content elements are accessedfrom a Web page loaded, by the local Web browser, via active screenelements such as hyperlinks, search boxes, dialog boxes, selectionbuttons and the like. If the local Web page is a carbon copy of a Website page, then some or all of these active screen elements will useURLs to locate desired content elements and these URLs may point toInternet addresses such as the originating server rather than to localstorage at the local station, preventing the browser from operating inthe desired offline mode.

To solve this problem, the invention also provides a link manager andrelocator function to adjust the hyperlink coding as needed to enablethe Web browser to retrieve Web page content elements from localstorage. The link manager can be either static or dynamic. A static linkmanager can be embodied in preprocessed Web pages or content as a simplerewriting of the original URL to a suitable local path, and filename aswell, if appropriate. Such a static locator device is appropriate for ashipped product supplied on physical storage media, and may beappropriate for updates supplied via direct modem-to-modem connection orequivalent, but a dynamic locator is more flexible and can be used forcontent elements or pages retrieved online from one or more Web sitesespecially for rapidly changing or complex content and advancedfunctions such as searching and transaction handling. Such a dynamiclocator can work with pre-existing URLs, as found on the Web site andredirect them on-the-fly to local resources. Embodiments of theinvention may place this link manager/relocator at the server or at theclient, and the static embodiments may be effected by eitherprogrammatic or manual procedures, as desired.

It will be understood that the above-described offline browser is quitedistinct from conventional applications, including even sophisticatedword processors, being distinguished, inter alia, by its ability to workonline, when necessary, to search the Web and retrieve informationobjects from it, employing hypertext links to remote resources and usingthe Internet's Transmission Control Protocol and Internet Protocols, orequivalents. Preferably, the local browser comprises search, display andhyperlink capabilities comparable to those provided by a conventionalWeb browser, with adaptations, as necessary, to enable local browsing ofthe content at the local station. Such adaptations may include the linkmanager; a local search filter for a Web search engine; and modificationof an online browser to load and run locally without automaticallyinitiating access to the Internet. In a preferred embodiment the offlinebrowser is developed from a standard online browser product, availablefrom any suitable source, modified and adapted as necessary to providethe offline mode functionality described herein.

However, a very simple offline browser according to the invention mayeschew direct Internet online access capability and be designed to workonly with locally stored Web pages, updates and new content elementsbeing received on physical media or via a dial-up connection. Especiallyif the local browser and station have multimedia capabilities, and thelocal content elements have auto-play capabilities such as are providedby Sun Microsystems' JAVA (trademark) language, ability of the browsertransparently to access multiple resources, CD-ROM, DVD (digital videodisks), hard disk, etc. by simply clicking “hot button” hyperlinks canbe employed in various new products. For example, a multimedia musicproduct can combine the music with text, still pictures or video aboutthe artist, and permit locally stored updates to be seamlessly mergedwith original content.

The new content element can be an update of a local content element and,preferably, is also locally stored and is transparently accessed andintegrated with other local content elements for viewing or processingby the user, for which purpose the herein described user interface anddatabase modules are those provided by the offline browser which acts inthe role of a containing information product.

Richer products will provide multiple Web pages for offline use and maycomprise large numbers of content elements which are updated with, orsupplemented by, multiple new content elements fetched as a package.

Such an offline browser system can be distributed by a commercialsponsor or content provider to simulate their Web site in a standaloneenvironment without the expense, difficulty and inconvenience ofestablishing an Internet subscription connection for those who do nothave one. To this end, selected Web site content, providing one or morepages, which may have a customized look chosen by the commercialsponsor, “local pages” hereinafter, can be supplied on physical mediasuch as CD-ROM or diskette and updates can be automatically fetched bythe transporter. The combination of offline browser and local pages maybe seen to be another embodiment of the containing information productdescribed in the parent application. The user interface, databasemanagement and other data integration functions described in the parentapplication are provided by the browser (augmented if necessary), insuch an offline browser embodiment of the invention.

Of course, as described above, the offline browser system can bedistributed as a shell which uses the transporter to fetch completingelements and content from a remote site, via a telephone network orequivalent network. By disconnecting, automatically if so desired, whenthe specified information object transport operation or operations hasor have been completed the transporter of the invention limits line oraccess charges. In contrast, with conventional online Web browsing timecharges continue to accumulate while the user views or processesreceived material. The transporter can be repeatedly reactivated on anas-needed basis to provide intermittent communication with the remoteserver or servers specified or user-entered in its setup protocols,thereby simulating the ongoing, open-ended interactivity of an onlineconnection with the remote server. Naturally, the Web site sponsor maychoose to modify the local pages as compared with their Web sitecounterparts, for example to simplify them, or to provide access tocontent or function intended by the sponsor for local use only.

The local pages will normally include at least one greeting pageintroducing the site and providing access to its principal features orcategories, and may also include many layers of functionality andcontent which can be jointly or severally updated by transporteroperation. Preferably, at least one local page pursuant to this aspectof the invention will be distinguished from a conventional Web page bythe presence of an update function, or hyperlink, for activating thetransporter to update that page or, if desired by the sponsor, to updatethe complete offline browser system. Different update links can employdifferent object manifests to use the transporter to fetch variouscontent according to the context of the update hyperlink.

In a further embodiment, the offline browser system of the invention canbe used in a larger context which combines local content stored onCD-ROM, or equivalent distributable media, (diskette or DVD forexample), with additional content from a hard disk, or equivalent andwith live browsing or data retrieval from a remote source, for example aWeb site on the Internet, via intermittent transporter or data shuttleconnections, “shuttling” herein. The inventive offline browser systemcan combine these resources in a coherent suite.

Thus, local Web content can be pre-distributed on CD-ROM or diskette foruse with the described offline browser system. This distributed, locallystored Web content can then be combined with more current, or additionalcontent obtained from the sponsor's Web site or other remote location byeither intermittent shuttling or live continuous browsing. This allowsuser selection of local, intermittent or live modes, as desired, or asavailable at any given time and place. Providing such multiple accesscapabilities enables a vendor or sponsor to distribute their product enmasse to computer owners or users with confidence that a large number ofprospects can use the product easily and currently. For example,diskettes might be given away with a computer magazine to be sure ofreaching a market rich in enabled prospects by any vendor willing tomake the investment to reach them. A different group are prospectivehouse purchasers, a group rich in computer owners and users, who couldbe given an initial diskette or CD-ROM containing a realtor's listings,and the inventive offline browser system for viewing and updating thelistings from a Web site or other remote server using either theInternet or the telephone network. This method enables the prospects tobrowse the realtor's listings offline at their leisure, and to update iteasily via either the Internet or the telephone network, as needed. Therealtor does not have to consider whether their prospect has an Internetaccess subscription, and the prospect does not have to worry about thedifficulties and costs of attempting to download extensive listings.

Clearly, it is in the interest of both the sponsor and the user for theoffline browser to work with current content elements. To obtain thebenefits provided by the present invention, as it relates to browsingWeb content, it is desirable for new online content to be retrieved, andstored locally so that the network connection used for retrieval may beterminated, (terminating time charges) and browsing can proceed on thelocal station.

Referring to FIG. 12, an offline browser 120 is shown running at a localstation 122 where local content 124 is available at any of variousstorage media, removable or fixed, such as disk, diskette or CD-ROM.Calls handled by telephone network 125 and routed to an Internet serviceprovider (“ISP”) 130 enable the Internet 126 (or equivalentresource-rich, standardized wide area network) to be accessed by offlinebrowser 120 via conventional online connection 128, if such connectivityis available and desired at the local station 122. A content providermaintains a Web site server 132, connected to the Internet via line 134,as a point of presence on the World Wide Web, and, additionally, a webpackage server 136 which is in communication with Web site server 132and is equipped and configured for direct telephone access by users viatelephone network 125 and telephone line 143. Web server 132 suppliesweb pages 138 to the Internet and selected Web pages or Web pageexcerpts are supplied to web package server 136 to serve as local pages140. Local pages 140, with relevant Web page URLs replaced withappropriate local paths or other local resource locators, if desired,can be retrieved via dial-up connection 142, if conventional Internetaccess is not available or desired. Clearly, an information product'sfunctionality or usability can be substantially enhanced by includingwith the local Web pages, whether supplied “over-the-wire” or onphysical storage media, any applets needed to run them, for example SunMicrosystems' JAVA (trademark) applets.

Content provider 143B can thus supply local station 122 with Web pageseither via online Internet connection 128, if the local station 122 hasone, or via other dial-up connection 142, if the local station does nothave Internet access facilities. The update can be stored locally andbecome part of the local content 124 where it is available for offlinebrowsing, avoiding the costs, delays and possibly, access problemsassociated with online or live browsing. Preferably, the local browserprovides user selection of local, intermittent or live modes, asdesired, at any given time.

It will be understood that connections 128 and 142 are typicallyalternative uses of a single physical telephone line, and thatalternatively, connection 128 could be any kind of direct Internet orother data network connection. It will also be understood that Webserver 132 and web package server 136 are distinguished in their logicalembodiments as distinct servers, which can be implemented either usingdistinct hardware and software systems, or as logically distinctelements on a single hardware platform. Also, preferred embodiments mayinvolve continuous, real-time connection between the servers 132 and136, for dynamic access to the Web content, or intermittent or evenoffline file transfer linkage, when static access is sufficient.

Sending of information from the user to web package server 136 can beaccommodated, if desired, using the bi-directional capabilities of thetransporter. In this case files of any type may be sent to the server136. Thus, specific information objects including features of theoffline browser and the associated HTML content, such as transmission ofdata entered into HTML forms, can be sent to the web package server 136,using appropriate Internet transaction protocols and associated securityand payment functions as desired, as depicted by connection 150. Such asystem provides a novel mechanism to support processing of formsincluded for example, in web packages, as described herein below, thatare filled out locally.

In more advanced embodiments, the linkage between web package server 136and Web server 132 can be used bi-directionally to provide enhancedreal-time services such as searching and transaction processing. Forexample, a response to a user's inquiry or purchase or product order,from a remote Web site can be received by Web server 132 and relayed bythe web package server 136 to be made available to the user via thedial-up path 142. Such an embodiment uses the gateway server functiondescribed in the parent application and shown as the vendor link 50 inFIG. 1.

Thus, the novel features of providing locally browsable Web pages 140,with replaced URLs, if necessary, and web package server 136, servicedby Web server 132, as described above, enables a content provider, orsponsor to provide a valuable new service: offline Web page browsingwith active hyperlinks.

Employing the user interfaces, database managers and API's describedhereinabove, the web package can be seamlessly integrated with existinglocal material employing hyperlinks, if desired, for immediatecross-referencing, or cross-locating of material as between the new andlocally pre-existing material.

It will be apparent that the UI/DB functions described for the noveloffline browser could be custom built or assembled from suitable browsercomponent toolkits, such as are beginning to appear on the market fromsuch sources as Spyglass, and that such offline browser function can beintegrated with other application functions as desired. However the wideavailability and growing installed base of standard browsers from majorvendors such as Netscape and Microsoft makes it preferable to employsuch a standard browser. In such an embodiment, the offline browser issimply a special case of a standard authoring package as described inthe parent application. In many cases off-the-shelf browsers can be usedeffectively, and even browsers previously installed on a user stationfor other purposes can be employed, by exploiting standard features forextending such products, including helper applications, plug-ins,applets, and API's.

Briefly, such mechanisms allow a standard browser to be used to viewcontent and select links to follow to additional content. In simpleembodiments, when the link target is locally resident, it may beautomatically handled by the standard browser; when it is not present,the link can, pursuant to the invention, be coded to cause the browserto invoke the transporter as a helper application. This is describedmore fully in the section below headed “Link Management”.

Also, if desired, local pages 140, with local resource locators, can besupplied to the Internet 126 for retrieval via online connection 128,for offline browsing, for example as an appropriately labeled offlinebrowsing package. This feature may be particularly useful for mobileusers, and the like for whom Internet service may be available oreconomic only on an intermittent basis. In this case content can beobtained in efficient bursts when access is available (or even on anautomated, unattended schedule, when convenient or low in cost), andthen stored locally for continuing use offline. Thus, the time of usageof online content is effectively decoupled from the time of retrieval ofthe content.

In contemplating the herein described applications of the invention toWeb browsing embodiments those skilled in the art will understand thatthe inventive approach departs dramatically from conventional conceptsof Web browsing architecture. Whereas conventional Web browsers are seenprimarily as communications programs, which gain strength by using astandardized user interface and data content framework (UI/DB), theinventive approach ignores (or, when used in conjunction with live oronline browsing options, downplays) the browser's role incommunications, and uses a browser primarily for its UI/DB components,relying on the inventive transporter for communications. And whereassession management is open-ended and conventionally is left to the humanfrailties of the user, the inventive approach uses the transporter 14 toenable task-oriented session management operable in a short burst orbursts to transport pre-specified objects (whose specification may wellbe unknown to the user and be embedded in a hyperlink or other softwareelement).

In addition, conventionally, helper applications, API's, plug-ins, andother browser extenders were devised primarily for addition of newcontent types, or enhancement of content, whereas the present inventionutilizes these tools to enhance communications techniques, and enablenew communications methods.

It will be understood that short-burst access to bundled packages ofcontent shown as using a dial-up connection 142 to reach the web packageserver can just as well use an Internet connection or other suitablenetwork, as described above, and under the heading “Equivalent Networks”above, and that such embodiments may become increasingly important inthe future.

Link Management

As referenced above, a problem that arises when attempting to integrateretrieved new content elements with pre-existing local content elementsstored locally at the user's station, is that, in general, the URLsassociated with any hyperlinks in the new content elements fetched froman online Web site will not correctly point to the user's localresources because, in the nature of URL's, (and particularly “absoluteURLs” as described below) they will point to a Web site, namely the sitefrom which they were fetched, or some other Internet Web sites. Thislink redirection problem may arise whether or not the content comprisesWeb pages, and is inherent in any updatable material that employshyperlinks where updates will not necessarily be stored in the samelogical volume as the original material.

A simple solution to this problem, pursuant to the invention, providesfor links to be coded as “relative URLs,” which are relative to thesource location and contain only relative sub-structure detail. Thelinks may thus remain valid if the substructure is relocated to thelocal station on a consistent, parallel basis, e.g. if remote pages arewithin a single directory, the relocated link will be interpreted aspointing to the single local directory. Thus, those elements of the pathand filename(s) that are recited in the link must be present at thelocal station: they could be installed beforehand in an offline browsersetup routine or by updates. Link coding may comprise truncation of theabsolute URL to remove elements of the Web site address or othermodifications as disclosed and suggested herein or as will be apparentto those skilled in the art.

While beneficial in many situations the solution of using relative URLswill not solve the more general problem of offline utilization of linksto scattered source materials, including remotely stored materials,where it may be impractical to maintain the relative structure, or where“absolute URLs” may be employed at the remote source. To solve theseproblems the invention provides, as referenced above, a link manager toredirect or rewrite URLs as necessary for local use.

For smooth and efficient integration of the offline Web browser systemwith online browsing activity, it is desirable for the offline browserautomatically to access the most up-to-date version of any particularcontent element, and if it must be retrieved from a remote source to beable to fetch it either via live browsing or by shuttle mode.Preferably, the local browser should fetch content from the network onlyif a local copy is no longer current. This capability requires amechanism to check time stamps of both network and local copies. Moreadvanced embodiments could use more complex and variable criteria forthis decision, such as factors for file size, type, urgency, andconnection availability, as well as relative currency.

To solve these problems the invention provides a dynamic link managercooperative with the local browser to manage link relocationsdynamically as links are activated. In preferred embodiments the linkmanager can operate efficiently regardless of whether content isretrieved via shuttle or live mode.

A variety of levels of sophistication in link management may be employedin embodying the invention, and depending on the functions required,link management may be static or dynamic at either the server or theuser station, or both. Key factors are the dynamics of the content interms of its frequency of change or addition, whether both shuttle andlive mode are to be supported, and the extent to which a user's localcontent is allowed to vary.

In maintaining proper linkage, a key concept is the idea of “workingsets” of web content. Linked content constitutes a network which is adirected graph. While in general, Web content is open and any home pagemay have links which lead to other links that go throughout the entireWeb, actual Web sites may be limited or can be artificially limited inthe scope of their links. Thus, the term “working set” is used herein tomean a set of linked objects which a user is permitted by a service,content or applications provider, to reference at a given time. Thisusage of the term “working set” is borrowed from the unrelated field ofvirtual memory management.

If the working set is kept sufficiently small, it may be practical totransmit all working set elements that have changed whenever the userrequests one or more pages in the set. In this case all pages in thecurrent working set are known to be available locally, so that links canbe pre-coded at the server to point to local copies (using relativeURLs, if they are not already coded in such manner). Then, desiredexplicit links for updates to current content, or planned extensions,can be coded to cause an intercept, and the handling of the intercept isused to invoke the transporter 14 to retrieve the update package for theworking set.

More generally, where the working set is too large for completetransmission on every update, and a scheme for segmentation of theworking set into smaller bundles of linked objects, called “webpackages,” herein which can be obtained from the server individually, asneeded, may be employed. In this case, as before, links within a webpackage may remain as simple relative URLs, which can be expected towork locally and can be followed by the browser without specialconsideration, but links from one web package to another need to beintercepted and checked to determine whether the destination object isin a local web package, and then proceed accordingly.

Pursuant to the embodiment of the invention depicted in FIG. 13, thelink manager comprises a link interceptor 144 cooperative with theoffline browser 120 to intercept links activated by the offline browser120 and take temporary control of the browser application threadwhenever a link pre-coded as not internal to the active web package isencountered. Intercepted links are inspected to determine whether theyare calling a resource available locally in another resident webpackage. If not, depending on the mode of access in use at the time,control is returned to the browser 120 for resource retrieval via livebrowse or is given to the transporter to perform a shuttle.

In a generalized embodiment, the link interceptor 144 monitors all linkrequests issued by the browser 120, cooperating with the browser bymeans of any of a variety of standard or customized mechanisms asdescribed below, and acts or passes them according to theirdestinations. To effect monitoring the link interceptor 144 can operateat a relatively high level, plugging to the browser's API, assuming itto have one, although this may require some customization of the linkinterceptor 144 to browser 120.

If the intercepted link is determined to be calling a locally availableresource, for example because it recites a filename identical with alocally stored file, it is passed to a link translator 146 to correctits destination. Control and the translated link are then passed back tothe local station's offline browser 120 for completion. Preferably, thelink manager includes a version comparator 148 which calls a versionnumber, time and date stamp, or other version indicator from theoriginal URL address on the Internet, compares same with correspondingdata for the local content and processes the more current version. Ifnecessary, the link manager can include a time and date stamp module(not shown) to label relevant links or link elements as they arereceived locally.

Preferably also, in applying such a scheme, the link translator 146reads from the intercepted link sufficient information to enable lookupand translation. Translation can be effected by appropriatemodifications of the URL.

Link control and interception cooperative with the local offline browser120 can be embodied at various levels and points of control. In a simplecase, all links except a single class of update link can bepre-converted to relative URLs that work without interception. Updatelinks can be coded to cause a standard shuttle update function to beinvoked, such as by invoking a packaged version of the transporter as ahelper application, using a coding approach such as described below.

In a more flexible embodiment using the web package segmentationstructure, web package-specific intercepts are provided and coding isapplied to the links to cause the browser to transfer control for linkrelocation purposes when specific intercepts are encountered.

In an alternative embodiment of link manager which requires no inlineediting of links or selective intercept control, the link interceptorintercepts all HTTP “Get URL” requests (in other words interceptshypertext transport protocol requests to get a file based on its uniformresource locator address, which has been left in its original form) andmakes a determination, based on separately maintained data, as towhether the target object is local, in which case it passes the Get URLback to the browser to execute as a local relative URL, or whether toobtain the target object via remote browsing or via transportershuttling. Interception can be implemented using browser API functionswhich are commercially available in various forms including for exampleDDE, OLE, and Netscape Communications' “Inline Plug-Ins”, or through useof proxy server functions, preferably modified for local users. Proxyservers are commonly used as intermediary servers that can redirect URLreferences in order to implement secure fire walls, but can also beimplemented in simple form to perform a comparable redirection functionrunning as a process on the user's machine cooperatively with thebrowser.

Conventionally, a proxy server provides a standard mechanism thatimplements an intercept/redirect function in the network (normallyapplied to the very different objective of resource hiding for purposesof security), outboard from the browser. When use of a proxy server isspecified to a browser, all “Get URL” requests are directed first to theproxy server, which then looks up the proper routing and redirects therequesting browser to the actual desired URL in a two stage process.Proxy servers are usually separate shared servers performing networkcontrol functions for entire groups of users, and the desired webpackage storage and access management could be implemented on a similarshared basis, but this activity is typically individual in nature andthus preferably effected at the user's station. Use of a simple proxyserver on the user station can be an effective mechanism for linkcontrol, if appropriately coordinated with any other uses of proxyservers, such as for security fire walls.

Alternatively, the link interceptor 144 may operate at a much lowerlevel and monitor suitable DOS or other operating system interrupts,such as interrupt 21 or 23, filter all browser originating resourcecalls, and process the filtered calls selectively according todestination, as described herein. Use of the operating system interruptsin this way may be more difficult to implement, but can provide a moreuniversal link interceptor 144 able to work with a variety of browsers.

Link Coding

Link coding is preferably done when the web packages are built, unlesslive browsing is to be supported with full or substantially transparentintegration of local and online resources. Links internal to a webpackage are left as (or converted to) relative URLs and need nointercept, although interception may be used for tracking purposes, ifdesired, enabling a user's “hits” on particular links to be logged andforwarded to a remote source using transporter 14. Such tracking doesnot require amendment or rewriting of links.

Pre-Coded Web Packages

External links are coded into the web packages, before delivery, so asto be intercepted and amended or rewritten. The intercept process can bemanual if static content builds are used, or semi- or fully automated,and can be varied, depending on the dynamics of content structurechanges, for example, as follows:

a) Web package definitions can be manually set up to consist of a set ofobjects, and this definition automatically applied to edit links in newcopies of the specified pages. In this case the web package is known toconsist of the pre-defined set of pages, and is thus static in pagecomposition, but the content of those pages is dynamic, and requiresdynamic link adjustment when new web package copies are built.

b) Alternatively, procedures for automatic segmentation of content intodynamically defined web packages can be used.

Dynamic Link Coding

If live browsing is to be fully integrated then link relocation can bedynamically coded locally, as pages are received. Preferably, the webpackage structure is used to simplify tracking so as to have similarcapability for dynamic web package definition as described in b), above.Alternatively, individually accessed pages can be tracked as single-pageweb packages (with any associated inline objects), and then consolidatedwhenever the opportunity and necessary information becomes available,such as on request, or when a web package is received that supersedesthe individual page.

In a simplified embodiment of this aspect of the invention, designatedpages can be retrieved one-by-one as standard pages (with associatedinline objects) from any server, or servers, but managed together, as apackage, by the client system at the user's station, as a defined webpackage object group (using separately maintained web packagespecification and control information) which can be termed a “virtualweb package”. Such a virtual web package has the benefits describedherein, namely that it can be supplied by direct dial-up using batched,managed access in a short burst for subsequent offline use. However, avirtual web package will lack the packaging-related transmissionefficiency of the described “real” web packages, although the need forseparate prepackaging or staging of content is also avoided by way ofcompensatory benefit.

One way of coding a link for interception on an exception basis, such asby using a helper application is by modifying the file extension of itsrelative URL or local file protocol URL, although at least in somecases, steps may need to be taken to avoid destroying file functionalityconferred by program-recognized extensions such, for example, as “.BMP”,“.TIF”, “.DXP”, “.DBF”, “.IDX” and the like. Simple substitution of anextension would lose the extension info, and but may be applicable forpages which can be assumed to be written in HTML.

Thus, for example, the existing file extension of the URL in the uncodedlink, whatever it might be, could be replaced with a common interceptextension, such as “.TSH”, which would cause the coded link call to beintercepted for rewriting when that link were activated by the user.Clearly, multiple coded extensions could be devised to serve a varietyof purposes, including, perhaps, usage tracking. This extension-basedcoding approach is convenient for simple embodiments in which theintercept mechanism is invoked by a special-purpose module orapplication, analogous to (though providing different functionalityfrom) the commonly available mechanism of a “helper application” whichis typically used to invoke viewers for special file types. Theinventive use of a helper application mechanism to manage communicationswhile using the browser for viewing is in some senses a reversal of itsconventional use.

To retain extension functionality and support more general absoluteURLs, a preferred coding practice pursuant to the invention, is toappend to the coded link, after the URL's intercept extension, one ormore additional legal URL coding characters such as “#” (used for tagswithin pages) followed by the original URL, with its functionalextension. Thus “image.bmp” could be coded as image.tsh#bmp, or moregenerally, for http://host/path/image.bmp, aslinker.tsh#http://host/path/image.bmp. The URL coding character would beignored by the browser, but would be accessible to the link managerwhich can delete the URL coding character and the intercept extension,rewrite or amend the URL and return it to the browser for execution,with its original extension intact. It will be understood that startingafter the initial “#”, all “/” and other special characters (such as “#”for a real tag) must be coded in the form of their hexadecimalequivalents using the standard URL escape characters, in the form “%00”,where “00” is the equivalent hexadecimal code, in order to conform tothe rules for a legal file protocol URL.

A more preferable alternative means or module to cause or identifyexception intercepts is a module that uses a special protocoldesignation to cause the linker to be invoked as a protocol handler,such as tsh.//image.bmp, or more generally tsh://host/path/image.bmp incases where the browser allows addition of new protocol handlers, assome recently available versions do. This scheme can also be useful inembodiments where all URLs are intercepted.

To effect URL translations, the link translator preferably comprises aseparate set of lookup tables. In addition to specific or wild carddesignations of original URLs, or URL classes, against corresponding newURLs or URL classes, separate lookup tables enable efficient tracking oflink status, time and date stamps, and other relevant link data, andalso facilitate grouping of translations and status by web package fortransport with a web package as a web package list, providing anintegrated product. Such a mechanism also facilitates the selection of avariety of Web pages from a Web site with properly managed links. It isnot necessary to modify all local references to a newly supplied webpackage in advance: the links can simply be intercepted and the webpackage list consulted live. Alternatively, the coded URL may carry withit a web package identifier for an entire update or extension webpackage instead of or in addition to the specification of a specifictarget URL, depending on the variety of access modes and richness ofcontent structure to be supported.

Such mechanisms are very effective for what might be regarded as passivecontent such as text, images and even multimedia retrieved by the userfor independent use at their local station, but greater difficulties mayarise with dynamic, changeable content, for example cases ofclient-server interaction needed for forms handling, searches image mapselections, JAVA (trademark) applets and push-pull content.

To carry out these dynamic activities locally or in shuttle mode theinvention provides local simulation of the server functionality tocomplete the interaction. As an alternative, a special server connectioncan be employed to effect the necessary server interaction in a short,automated session. Such innovations are believed feasible but somelimitation of functionality may be desirable. Forms can be included inweb packages as blanks, and sent in to the server when filled out.Searches can be passed as standard Web searches, or selected resultpages could be included also to avoid a subsequent reconnect. Image mapscan be converted to local image maps and push-pull can be facilitatedwith local scripting, as desired. JAVA applets and live objects, such asdirector movies should run satisfactorily locally given necessarybrowser support.

Other schemes for coding links to achieve the purposes of the inventionwill be apparent to those skilled in the art who will also understandthe value of the novel link coding capability of the invention inenabling many useful applications, including web packages with activehyperlinks, as described.

Web Package Utility

Such novel web packages in turn can stimulate a variety of newapplications and ways of using Web content or other material compatiblewith Web standards, especially when combined with the transporter of theinvention into automated web package transport embodiments. For example,ready access to web package content furnished by a sponsor from a remoteserver using the transporter for user-driven dial-up retrieval of thecontent can introduce non-Web users to Web content and attract them toonline services, adoption of which can be facilitated by incorporationof a Web or Internet access provider's subscription package (or enablingshell) in the Web package.

Web Page Caching

It will be understood by one skilled in the art, that the linkmanagement modules and methodology of the invention, and its applicationto web packages, as described, are quite unlike conventional web pagecache managers commonly used by browsers temporarily to hold recentlyaccessed pages at the local station for subsequent quick access.Conventional local Web page cache managers are not presentlystandardized, making it difficult to communicate therewith via anextension module such as the inventive component for direct dial-upaccess and suffer from the drawbacks that communications access isassumed to be readily available at all times, to replace or add pages,and cached objects are automatically purged under simple policies suchas “least-recently-used”. Thus the content of conventional Web pagecache managers is transient in nature rather than persistent and thecache managers are unsuitable for effecting the offline browsing andother link management functions of the invention, as described above.Furthermore, such conventional Web page cache managers currently neitheroffer nor can readily be extended to support the required set of linkmanagement and relocation features described herein.

Nevertheless, in one preferred embodiment of the invention, aconventional Web page cache manager can be used to enhance theinvention, for example, in a case where the browser (and associatedcache) is custom built for use in online and shuttle mode, or where anadequately featured cache facility is standardized and generallyavailable across a useful population of browsers. For these purposes,the conventional browser preferably provides, or can be extended toprovide the necessary functionality, and offers a suitable API or othercontrol interface, to manage the local objects.

As noted hereinabove, it will be understood that the described approachto link management applies to remote hyperlinked content in general,whether based on current URL usage or current or future variants,extensions or other equivalents of URLs. This includes object-orientedapproaches to the handling of hyperlinks using object containers forURLs or other hyperlinks, such as those known in the art as “monikers”.

While described to serve the purposes of offline browsing, it will beapparent that the described link management features of the inventioncan be employed in other situations where it is desired to redirectlinks.

Link Management Applications

The ability to manage links as described herein, enables a number of newWeb capabilities to be provided, serving various recognized andpreviously unrecognized needs. Properly implemented, using the teachingsof the invention, a user can smoothly interwork local, shuttle and livemodes for static content formats, for example HTML, images, multimediaand the like. Some applications of the link management aspects of theinvention to filling these needs will now be described while others willbe apparent to those skilled in the art, or will become apparent as theart develops.

Content Archiving and Relocation

The link interceptor function can be modified to perform many othervaluable functions to add value to the basic hypertext functionsprovided by the standard network protocols. For example, currentprotocols provide no facility to deal with links which point to contentwhich has been moved or deleted, or which reference a server that is nolonger maintained to be accessible on the network, or which is otherwise unavailable: they simply cause an error message to be displayedwhen such an “empty” link is selected. As at the date of thisapplication such empty links are a relatively minor nuisance. However,their proliferation will become increasingly problematic as linkedcontent developed by uncoordinated and perhaps undisciplined sourcesgrows and evolves. Eventually these empty links could seriously impedeInternet traffic, like so many parked cars on the highway. A proposedsolution yet to be standardized by the Internet Engineering Task Forceinvolves the use of new forms of link specification which embed indirectbut permanent Uniform Resource Names instead of URLs, but this is sometime off because of complex policy issues, and has the drawbacks ofrequiring changes to embedded pointers in existing content, and imposesa relocation overhead on every access. A stopgap approach similarlybased on embedding indirect links, called Persistent URLs, has recentlybeen proposed by the Online Computer Library Center, but has similarweaknesses.

Pursuant to an extended embodiment of the invention, browsers can bemodified, using the various browser modification or extension facilitiesdescribed herein, or their equivalents, to provide a solution to thisproblem that needs no change to current content and imposes overheadonly on an exception basis.

Thus to solve the problem of “empty” links the invention provides amodified browser including a link management module to react to messagesgenerated by failure of a link owing to an inadequate response from itsdestination by calling an enhanced version of the link interceptormodule, which includes one or more link search components which isinvoked to seek to alternative locations for the desired content, or anexplanation of its unavailability, and then provide an adjusted linkpointer back to the browser for presentation to the user. As time passesthe number of aged or obsolescent links must be expected to become quitevoluminous, spawning the need for a link relocation or archive server tomaintain the alternative location or explanatory data needed by linksearch components at the browser. The invention includes such a linkarchive server as well as modified browsers, as described, intended towork cooperatively therewith, whether in online or offline mode.

A variety of computer-implemented software mechanisms can be used bysuch a link archive server to provide an archiving and relocationservice, pursuant to the invention. Preferably, one or morespecial-purpose archive and relocation servers is set up to maintainrelocation information and, optionally, copies of the “lost” contentfrom the empty links. A link interceptor module at the user's stationcooperative or integral with their browser, is configured to query therelocation servers with a failing URL, and receive or retrieve aresponse containing a corrected URL, if known. Thus, for example, if apage at:

http://server1.com/path1/page1.htm,

was not found, the link interceptor could be configured to query either:

http://archive.com/relocator?server1.com/path1/page1.htm, or

http://relocator.archive.com/server1.com/path1/page1.htm,

as a first relocation server to be checked.

Information on such relocations could be submitted to the relocationserver through various means, and an active “spider” process could beapplied, being initiated, for example, from the relocation server, tomonitor the structure of the Web and detect changes. The spider wouldsave the content or preferably a short coded signature for each page,and then on subsequent scans, would identify relocated pages, using thesaved content or signatures, and note the new addresses for respondingto inquiries from the link interceptor. Preferably, any relocations thatwere uncertain would be flagged with a coding that would allow theviewer to be warned of the possibility of error. Such archive serverscould also offer an optional repository service for useful pages nolonger maintained (or maintained in some new location) by the originalsource or sponsor. The relocation and archive servers could bemaintained as a for-fee service, or sponsored through various mechanismsincluding advertising, as are search sites, currently.

Where feasible for content servers which remain operative but havecontent that has been moved or deleted, an alternative, and perhaps moredesirable method, of implementing such relocation functions would be atthe content server, preferably by convention. Thus, for example, aserver could add a basic relocation server function for pages that hadpreviously been available from that server. Thus, for example, if a pageat:

http://server1.com/path1/page1.htm,

was not found, the convention could be to query either,

http://server1.com/relocator?path1/page1.htm, or

http://relocator.server1.com/path1/page1.htm,

as a first relocation server to be checked.

Screening

The link interceptor module, when configured to intercept all orselected external links or Get URL requests enables user activity to bescreened so that undesired requests can be denied or filtered out. Sucha screening process can be used to prevent users retrievinginappropriate content, for example content judged indecent or obscene,or from competitors Web sites, so long as an address, or URL, for thatcontent is known. If the user attempts to get an URL on the excludedlist, “Object Not Available” can be returned.

The link interceptor module can access a list or table of excludedaddresses which may be maintained locally or accessed at a remote site,the access or a periodic refresh can of course be effected bytransporter 14, if desired. Where a third party, for example theInternet Service Provider (“ISP” herein) can furnish descriptiveclassifications of site content, by address or URL, as being indecent,violent, politically incorrect or the like, and password coded setuproutine can also be provided enabling a supervisor of the local stationto filter out certain categories of content. Thus, a parent can use apassword, or multiple passwords to control what content their childrenview.

It will be appreciated that the link management, intercept andrelocation aspects of the invention, and the concept of relative URLswhile being particularly advantageous in assisting the implementation ofoffline browsing, as described herein, can be beneficial independentlyof the use of transporter 14, for example to enable offline browsingindependently of dial-up updates or to enable an URL-driven contentscreening module which could be a freestanding software component orprogram implemented at the user's station to screen the user's activityor at the ISP to screen or censor all link calls from the ISP'scustomers, or elsewhere, as will be apparent to those skilled in theart.

Web Package Assembler

The invention also provides a computer-implementable web packageassembler enabling sets or packages of Web pages, as describedhereinabove, to be assembled into useful web packages from contentavailable at diverse locations on the Internet. A key component of sucha web package assembler is a link relocation module to rationalize allhyperlink references within the package, for local browsing.

Other useful components which can be included in such a novel webpackage assembler are a selection tool, a retriever and a packageassembler. The selection tool specifies the desired content ingredientsof the web package in a manner susceptible to search and appliescriteria to select suitable content elements from an existing contentset which may be as diverse as a single database or directory of data orall Web site data available on the Internet. The retriever applies theselection tool over the content set to gather content elements for theweb package, or alternatively to gather a superset of content elementsfrom which the web package can assembled.

The package assembler uses the selection tool to assemble a desiredspecific package or web package from the content elements generated bythe retriever. These tools will now be described in more detail.

Web Package Selection Tool

A preferred web package selection tool provides a time-optimizedselection process to economize on connection charges and which uses afocused methodology to achieve a brief connection. Because of thevastness of the World Wide Web, and the extent of its content, it isimportant that the selection tool apply a range of filters or selectioncriteria with optional specification or customization or plug-in controlof parameters for content, source, quality, style and other parametersthat will be apparent to those skilled in the art. A particularlydesirable feature is an option for explicit specification of desiredcontent known to exist on the Web, for example Web pages previouslyvisited, and preferably means (e.g. drag-and-drop, paste-and-copy, or aseparately windowed routine employing a file manager) are provided tofacilitate such desired content specification for example by postingrespective URLs from the user's hotlists, cache of visited sites,vendor- or sponsor-supplied list or other offline (or onlineretrievable) source of URLs of potential interest.

The objective is to build a coherent package comprising a hyperlinkedcollection of content elements retrieved from multiple Internet (orother appropriate dispersed source) locations, the content elementsbeing handled and built in an environment of their original HTML orother standardized language, without requiring conversion to proprietaryapplication formats. Options for offline testing of a search query builtfrom multiple parameters, are desirable, where feasible, to avoidunnecessary or excess connection time.

Retriever Tool

The retriever tool uses the search tool and crawls across the Web, likea Web spider, to locate and retrieve desired or suitable content, basedon defined criteria, in HTML format.

The analogies to a spider web and references to a Web spider and Webcrawling are used to denote an organized search of Web sites involvingvisits to those sites rather than merely scanning the content of one ormore search engines. Clearly, a comprehensive search of the contentavailable at any and all Web sites is a time-consuming project. Crawlingtechniques can also include the pursuit of hyperlinks to relevantcontent, and other techniques, as are known to those skilled in the art.

Such a combined search-and-retrieve tool set can be used for otherhyperlinked, searchable content bases, as desired.

Package Assembler

The package assembler provides assembly of desired retrieved contentelements into desired web packages combining them with any appletsrequired to run, display or otherwise use particular content, or anyother appropriate accessories.

Link Relocation Tool

The link relocation tool operates like the link relocation moduledescribed hereinabove to effect appropriate changes in links in theretrieved content. The link relocation module provides functionality toadjust hyperlink references in the retrieved content elements to pointto other elements within the web package or, as appropriate, to point toother content elements in separate web packages which may also beretrieved, or otherwise to be rewritten or redirected, as describedabove. Proper resolution of links enables the tools to be used formanaged retrieval of related packages as sets, rather than as individualpages as in conventional Web browsing.

Appropriately used, these tools enable the building of a web package, ofmultiple pages from diverse locations, to be automated, combining Webcrawling under specified search constraints.

While these tools will clearly have utility at the user's station, apreferred embodiment of the invention locates them on a web packageserver accessible to users by direct dial-up connection. If desired, theweb package server can be provided with facilities dynamically toassemble batches of content elements into standardized or customized webpackages. Standardized web packages might for example be news items fora trade news letter that have been located at and retrieved from anumber of sites relevant to activities in the trade, are distributed toa population of users, whereas customized web packages, which arepreferably dynamically assembled upon request, are intended for anindividual, or small group of users, meeting their specific contentrequirements.

The application of this package assembler, and in the case of dynamicweb package construction, its use in conjunction with the abovesearching and gathering activities impose novel design constraints inthat packages to be transmitted must preferably be compact, and anycontent gathering done in real time must preferably be done in a waythat minimizes call duration. This affects decisions as to how tosearch, which items to select, and in what form to present the results.For example, size may become a parameter in determining which searchresults to remit to the requester. The issues and solutions of thesedecisions will generally be apparent to one skilled in the art, but mayvary from those typical in conventional online searching situations, aswill be apparent from the teachings herein. For example, when webpackage construction is dynamic it will typically be desirable to applya caching facility to keep frequently requested pages or sets of webpackage elements available at the web package server in order to keepaccess and assembly time to a minimum.

Short-Burst Connectivity

By efficient management of the communications process, the inventionenables calls to be terminated when pre-specified information objecttransfers have been satisfactorily executed, and furthermore enables thecomplete call process from dial-up to hang-up to be dedicated toautomated fulfillment of the user's instructions in a single short burstconnection the duration of which can be optimized by thetransporter-related functions described herein. This efficiency is incontrast to a typical online session where the connection can remainopen, running up time charges, while the user reads and thinks abouteach page retrieved (or is interrupted or performs other tasks), andlong after data transfer has ceased, unless the user alertlydisconnects. It is typical for such “think” time to be 10-20 timesgreater than the actual communication time. In addition, the compressionand object packaging or bundling features of the transporter can enablestill greater efficiency in communications as compared with conventionalInternet or other online access, which typically retrieves uncompressedpages or messages, one at a time by enabling compressed data transportto be implemented transparently to the user.

E-Mail Retrieval

In a simple example, new e-mail may be retrieved and browsed while stillonline, with a meter running, whereas retrieved new mail could bebrowsed just as effectively off-line. Employing the inventivetransporter, with suitable adaptations at the host server, the user canfetch a manifest of new mail, edit the manifest, if desired, fetch thenew mail and automatically disconnect or, alternatively, disconnect afirst e-mail service and call up one or more other such services, in asubstantially automatic manner once configured.

Similarly, the inventive transporter can be used to access bulletinboards and pull-down objects relating to particular content threads ofinterest to the user.

Known, special purpose e-mail readers for short burst access to specifice-mail and bulletin board systems are special-purpose modules configuredto fetch only mail objects addressed to the calling user, not objectsspecified in a manifest, and thus are not suitable for broadcastinformation object distribution, or publication. Unlike the manifestemployed in the present invention, any list of files attached to ane-mail does nothing to provide for further action upon receipt of thelisted files nor, because it is embedded in the e-mail message, can itbe employed by a user, information product, or remote server to specifyfiles or objects to be fetched. Nor do such e-mail readers compriseseparable software transporter components applicable to general-purposeautomated information object transport via managed dial-up connections.The ability to optimize the communications process and automaticallyterminate it with a disconnect for an arbitrary variety of applicationcontent, including Web browsing and searching, uniquely disposes theinventive systems to provide a novel, general purpose short burst dataretrieval facility for off-line users as described herein, which isquite different from the limited dedicated functionality of e-mailreaders.

Short burst connectivity can simulate an online environment by couplinga transporter with one or more hyperlinks, hot buttons or menu selectorsenabling a user to effect multiple or repeated data retrieval operationsin short bursts from one or more remote sources, by clicking on linksand hot buttons while they browse. In special cases, where a dial-upsource for the destination information object of the hyperlink is knownto be available, a translation or readdressing module couldautomatically post appropriate header and other retrieval data fromhyperlinks in imported content to the transporter and create a manifestfor fetching the object from the dial-up source, enabling an onlineenvironment to be simulated. Such application of an intermittent,short-burst connectivity approach to browsing and searching ofrelatively extensive content (such as collections of Web pages) is quitedistinct from conventional Web browsing and searching activities whichfunction as a fully online, continuously interactive process. Absent theteachings herein, conventional wisdom would expect the inventiveapproach to be unduly static and limiting of interaction.

With present-day modems, some delay occurs in the dialing and handshakeprocess which slows the dial-up communication process and may somewhathinder simulation of an online environment. Advancing technology mayreduce these problems increasing the usefulness of the invention.Connections via ISDN are established much faster, while connect timeappears at present to be significantly more costly. Accordingly, shortburst embodiments of the invention have particular application to usevia ISDN networks where retrieval of cumbersome graphics, video andmultimedia files may be important. The transporter can readily beadapted to offer a scheduling function providing users with an option toeffect retrieval of bulky objects at an off-peak low rate or low traffictime, such as at night.

Using such short burst data retrieval, a user can interact off line,seamlessly merging retrieved data or objects with local data or objects,in a rich and varied environment which may simulate an online session,without the expense and inconvenience that sometimes accompaniesextended online sessions. In many instances, for example domesticenvironments, freeing up a telephone line will be an important benefit,especially to teenage computer users whose parents require a singlephone line to be available. These benefits of short burst communication,with minimal use of phone lines, accompanied by off line browsing, areof particular value in the case of interactive digital music CDS, forexample, as supplied under an industry standard, or agreed format, suchas Music Enhanced CD. Application of the invention to this environmentwill be described in more detail below.

The short burst access characteristics of the invention may be ofparticular value to mobile users who often do not have suitable accessto adequate communications facilities. Wireless links are relativelyexpensive and slow, and while improving, can be expected to remain morecostly and lower in speed than wireline service. The ability toconcentrate activity into short, efficient bursts, and to pre-positionselected working sets of current content such as price lists anddocumentation in a portable system can be of great value to salesmen,field workers, and computer-using working travelers of all kinds

It will be apparent that applications of short-burst, intermittentconnection can be extended to provide broad support for contentsearching, and for efficient packaging and transmission of the resultingcontent, as well as for transaction processing in general, as referencedabove, for example by automating and managing communication with aremote search engine. In doing so, the implementation details of thetransporter functions and interfaces would preferably be tuned andadapted as appropriate to efficiently and effectively serve theparticular purposes addressed by various useful sub-classes ofapplications, as will be understood by one skilled in the art from theteachings herein.

Transaction Processing

As described in the parent application, the invention provides aflexible vehicle for transaction processing in many different ways viaboth real time gateway connections and non-real time store-and-forwardlinkages. Such transactions can be EDI-compliant, or use otherremote-ordering protocols for real or de facto standards including HTMLforms and Sun Systems JAVA (trademark) applets, and gain the benefits ofshort-burst communication optimized for reduced communication time. Inthis manner the benefits of the inventive transporter can be obtained ina way that interworks with and applies useful portions of transactioncontrol, user interface and security software infrastructure that may beavailable for use at the user and transaction server ends of thetransaction chain.

Moving web packages in or with a transporter, both as described pursuantto the invention, creates what may be termed a “web package shuttle”.With the short-session and simple connection advantages the inventionprovides, a powerful general purpose transaction processing capabilityis enabled having advantages similar to those described for informationtransport. Such a transaction processing mechanism can adopt any otherrelevant aspects of the invention described herein includingintermittent or short burst repeated connections, gatewaying between avendor or sponsor's server or a special purpose server and a Web serveror Internet point of access so long as HTML form-based transactions, ortheir equivalent, are supported. Store and forward is also useful inthis context so that many transactions can be collected on aspecial-purpose server for later processing elsewhere.

Interactive Music Products

The Music CD Extra format is a standard supported by Microsoft, Sony,Philips and other industry leaders for a class of high quality recordedaudio products distributed on CD with CD-ROM compatible user,multimedia-capable interactivity, enabling users to enhance the musicexperience (stored in ANSI standard CD audio “red book” format, playableon standard CD audio players) with suitable ancillary content such asliner notes, pictures, video clips, artist data, lyrics, discography,concert schedules, fan club information and so on (encoded in CD-ROMcompatible ANSI standard “yellow book” format, playable on standardCD-ROM players).

Variant combined formats have seen limited use, and all of these arecollectively referred to as Enhanced CDS. Comparable standards andformats promoting interactive environments for recorded products may beexpected for other media and products, for example video products andDVDs, as well as High Density CD, the DVD-based follow-on format for CDaudio and CD-ROM.

Such interactive music products may also include online links to the Webor other online services. However, to the inventor's knowledge andbelief available products provide or require traditional open-endedonline sessions with their associated drawbacks.

The invention provides a novel interactive recorded music productcomprising, stored on distributable physical media, a music recordingand an information transporter as described herein, coded for automatedcommunication with a pre-specified remote content source, particularly,but not exclusively, a digital music CD, which preferably also includessupplemental interactive capability relevant to the music recording.

Typically, the remote content comprises ancillary content as describedabove. The remote source preferably comprises a server maintained onbehalf of a vendor or sponsor of the music product accessed by directdial to a number stored or retrievable via a number stored, by or for,the transporter. In a preferred embodiment, a commercial vendor orsupplier of the music product maintains a server with ancillary contentof interest to purchasers of the music product and pre-installs thetransporter with an 800 or ordinary phone number providing automatedaccess to that server. Either in the original product or in an objectautomatically fetched by the transporter, a content list of availablechoices can be provided, enabling the user to select desired objects tobe fetched. When the selected object or objects has been satisfactorilyretrieved, the transporter or an associated user interface, eitherterminates communications or gives the user the option to transportanother object to or from the remote source.

Alternatively to direct dial access to a vendor-maintained remoteserver, the transporter can be coded to access the Web or equivalentonline network, via an access provider, to retrieve one or morespecified information objects from the Web using an URL, and toterminate the online session after receipt of the specified objects. Ifdesired after retrieval of an object via the online network,confirmation, or other data can be returned to a pre-designated servervia direct dial to that server, bypassing the online network.

A music industry application of the invention can thus embody theinventive offline browser system described above, as a musicsupplementer system, particularly adapted to the requirements of MusicCD Extra and Music Enhanced CD formats providing useful benefits tousers lacking online subscriptions.

The music supplementer system (“MSS” herein) can comprise an offlinebrowser system with direct-dial support, a local browser-viewer modulewith HTML Web page viewing functionality, and preferably with a base setof content elements in HTML format with optional selections of standardWeb content or other material for example Adobe's ACROBAT (trademark) orother viewers. The base content elements can conform to an enablingspecification appropriate to the MSS and can include any desiredcontent, for example, a basic home page, a tour schedule page, amulti-media download page, a fan club page, a merchandise page, a newspage and an artists or other artists page. Preferably, any links onthese pages are edited, modified or managed for local execution asdescribed herein. Such pages can be functionally modified versions ofonline available Web pages, as described above. Key functions can becontrolled and customized using HTML pages, or in other appropriateways, while the invocation of control functions can be done byintercepting links employing a helper application, or via API or viewercustomization or other means as described hereinabove.

Various special-purpose useful links can be provided, for example, a“Get Update” link in a home page that refreshes base content byretrieval from a remote source and provides specified optional elements.

Links to optional items for download can trigger transporter functions,as described, to fetch the optional item object if it is not presentlocally or can simply invoke the object, or a viewer for the object, ifit is present locally. Such objects could, for example, include audio orvideo samples.

Transaction pages, simulating actual Web pages, if desired, can beprovided to trigger sends to a remote server to enable joining a fanclub, or ordering merchandise, or other user-initiated transaction.Simple transporter send functions can be used for informationsubmission, such as product registrations, and server response andgateway functions can be employed when a response or confirmation isneeded.

A user control facility to edit a fetch and send list for thetransporter activatable from any desired page can also be provided.

A client system content control component or function, to be implementedat the user's station, to track the presence and status of informationobjects on the user's storage facilities, including any CD-ROM and harddisk can be provided to control link execution and editing, along with alink manager, as described.

Online Network Charging Mechanism

A drawback of a distributed online network, such as the Internet, whichlacks central administration is the difficulty of implementingconvenient charging mechanisms. Telephone networks provide a number ofcharging options, notably, caller-paid charges, collect calls whichreverse charges to the called party, subject to the called party'sselective approval; sponsor-paid 800- and 888-calls where all calls arepaid by the called party; and caller-paid 900-calls which provide forrevenue splitting between the telephone company and the called party.

Such services are not generally available on the Internet. Credit cardsare now being widely used on the Internet, although some people havelingering security concerns. However, though useful for major purchases,credit cards are not suitable for small time-related charges and do notoffer a medium enabling sponsors to provide free access. StandardInternet charging methods require establishment of a subscription withan access provider such as one of the major online services, for exampleCompuServe and America Online, or with one of the specialized Internetservice providers, and generally include usage (time) related charges(either explicitly or implicitly). This approach has the drawbacksdescribed above for casual, first-time and occasional users and limitsthe marketing uses of the Internet.

Networks managed by centralized service providers for example SPRINTNETor BT TYMNET (trademarks), offer systems enabling such networks tosimulate some telephone network charging capabilities. Thus the X.25standard for packet switching networks provides reverse charging optionsand a call-negotiation process that determines whether a called serveror host will accept collect calls. A caller or user must supply a billedaccount ID and password for caller paid charges or may be furnished witha special reverse-charge account ID and password.

X.75 standards permit call negotiation and reverse charging mechanismsto be applied across interconnections between individual X 25 networks,allowing some global coordination. Internet protocols do not provide forsuch call negotiation and charging management. The packet-switched X.25model does not appear to solve the problem of overcoming the accessproviders charges and formalities that impede novices and casual usersand prevent true, casual sponsor-paid access by any modem-equippedcomputer user to the sponsor's Internet site, because it is specific tothe X.25 protocol and no provision for an equivalent capability isprovided for in the Internet protocol.

To solve these and other problems, the invention provides an Internetcharging mechanism, including computer-implemented enabling software, inthe form of a charge-management module to be applied as a higher levelprotocol above the enabling online network protocol such for example asthe Internet TCP/IP protocols. The charge-management module preferablycomprises user, server and access point components operated at the nodesor points of access to identify collect and other calls at each accesspoint, to provide session-negotiation functions and to determine if acalled server will accept charges before a call is completed. Hosts thataccept collect calls can have an option of selectively controllingaccess to specific account IDs.

User components of the charge management module preferably include auser interface button or other selection requesting sponsored access toa resource and which is effective to activate the charge managementmechanism on the network, or such requests could be an automaticdefault, or implied by the URL specified. The access point module cancollect usage data for calls made via the access point operator andgenerate bills and call details for the sponsor. The sponsor or servercomponent screens and authorizes or rejects call requests received fromthe access point. The details of this process could be specific to asingle ISP to work among users and servers directly connected to itsnetwork only, but preferably a common coordinating mechanism analogousto X.75 could be used by a large number of cooperating ISPs.

900-number equivalent revenue-collecting functionality can be providedby means of a billing gateway server established to manage session setupfor revenue-generating calls using specially charged account IDs. Thebilling servers can allocate a caller's account and credit status,identify the pricing algorithms to be applied for the called server, andmaintain an activity record for end-user billing.

Such increased flexibility in charging can enhance and facilitatewidespread use of the Internet for both short-burst connectivityapplications and for fully online applications. Coupled with thecapabilities of the inventive transporter, such novel chargingmechanisms can enable new Internet (or other online network) marketservices such, for example, as allowing non-subscribing users to obtainfree sponsored service, or to obtain service-for-fee on a discrete,ad-hoc, time-of-need basis.

Intermittent Web Searching

Searching of the Web, or Internet, or other adequately standardized widearea network replete with data sources, can be understood andaccomplished using the transporter as a special case of transactionhandling, using similar mechanisms to those described above fortransaction handling.

Thus, a search request is simply a send transaction to a search engine,which responds with a fetch object (also referenced as a “responseobject” in the parent application) comprising a result list or hit listof objects found to match the search, which is then returned to theuser, at which time a disconnection can be made. This result can then beused as normal hyperlinked content to obtain the actual target objectsin a subsequent request, or a revised search transaction can besubmitted. In a similar manner to what was described in relation tobrowsing, the effect of an ongoing interactive session for searching andtransactions can be simulated by a series of short bursttransporter-implemented connections.

This intermittent mode of searching can be further exploited usingtechniques such as those described in the parent application forcombining indexes or other content into a single seamless search. Asdescribed, an index (or content set) on CD-ROM could be supplemented byan updated supplementary index (or content set) that had beensubsequently retrieved to hard disk. It will be apparent that thesearching-as-transaction approach can be used in the same way tosupplement information already retrieved. For example, a search ofcontent on CD (and hard disk) which is current as of a given date can besupplemented by a search transaction requesting the same search, andadditionally specifying that the results be limited to content with adate more recent than that given date. In this way, only the new itemsnot already present would be retrieved, for optimum efficiency in searchand transmission time. The result can then be merged with the localresults to produce a fully current, complete result (again sorted inwhatever order is desired). This approach permits very significantbenefits, for example in the case of the searching of general purposeInternet indexes such as YAHOO or LYCOS (trademarks), where repeatedidentical searches may be done weeks or months apart, with redundancy inall but the most recent results, only the incremental content needactually be obtained and transmitted. Since much Internet activityconsist of just such searches, the processing and communications costsavings are potentially very sizeable. Widespread adoption of suchconnect-time optimized search techniques could even help economize onInternet traffic.

Back Channel for Interactive Systems

A further valuable application of the information object transporter ofthe invention is to enable a novel interactive communications system byproviding back-channel communications via dial-up connections from apopulation of users to a broadcaster distributing analog or digitalmaterial over a one-way primary channel, such as TV air, cable orsatellite or data subchannels. Employing a configuration as described inLevel 1, this is primarily a send application, where users send objectssuch as a customer service responses, video program requests, or thelike back to the broadcaster, or a vendor coupled to the broadcaster, bydial-up, or equivalent, over a telephone or equivalent point-to-pointnetwork.

Optionally, the inventive transporter may be used to fetch objectscommunicated over the primary broadcast channel. In this case the activerequest for a fetch object in the manifest could be effected in variousways depending on the nature of the network and the request. If therequest were for a standard object scheduled for transmittal via theprimary broadcast channel, the transporter would simply request of thelocal broadcast interface that the object be provided when received.Custom broadcast transmissions could be first requested via a sendthrough the back channel as described above. It will be understood thatfetched objects may be transmitted over either channel, with the bestchoice depending on the characteristics of the network (including anylocal station addressability characteristics), the content, and thetraffic patterns.

Web Publishing

Prior to the date of this application, the concept of publishing on theWeb has become a commonplace. Publication is achieved simply by postinga Web page or pages at a Web site where any Web user is free to examinethe posting. In addition, it may be assumed that one or more searchengines will eventually locate the content, leading interested browsersto the site, and links leading from other Web sites may be set up.Unlike publication in the more commonly understood sense of massdistribution of copies of a document or other work, Web publication ispassive in nature: a single copy of the work, assembled according to Webstandards, is posted for browsers to read and copy, rather like adocument in a library.

Thus, a would-be Web publisher merely has to prepare their content andpost it to a suitable site. Since Web sites are computer servers locatedremotely from the ordinary user or browser, and an ordinary user mayhave difficulties in mastering the complexities of transmitting files tosuch a server, it will be apparent that the inventive transporterprovides an excellent means of facilitating the transport of documentsor other objects from their would-be publishers with local,modem-equipped computer stations, to a Web server via direct dial upconnection, using any appropriate ones of the tools and architecturesdescribed herein. Equally, the transporter can be used to shuttleacknowledgment and other publication confirmation details back to theoriginating user. In such an application users will typically have basicInternet connectivity, and this will preferably be employed by thetransporter. A benefit of using the transporter is simplification of thetransaction for both the user and the service provider.

Thus the transporter can provide an automatic upload includingconnection, interaction with a user interface to enable selection offiles for Web publication; execute a send to load the content to a Webserver, a logically distinct server which may be accessed via adistribution server, as described herein, and, if desired, submitted toa search engine via a gateway connection, also as described.

New or improved electronic information products are made possible by thenovel information transporter disclosed herein, for example,CD-ROM-based products updated from online services, updatable periodicalmagazine collections, catalog-based computer shopping with order entryand optionally, order confirmation.

Recently Contemplated CD-ROM Products Updatable from Online Services

A CD-ROM-based product with online service updatability called“MICROSOFT Complete Baseball” (MICROSOFT is a trademark) was announcedby Microsoft Corporation apparently on Mar. 1, 1994, with a Jun. 15,1994 availability date. A product brochure received by the presentinventor on April 26 describes a multimedia history of baseball whichcan be updated with daily scores from an online service, by modem.Nothing in the sales materials suggests any separable informationtransport components marketable for use with other information products.

In late April 1994, CompuServe® (trademark) online information serviceannounced plans for a CD-ROM information product to be used inconjunction with its online service. The CompuServe® CD-ROM informationproduct online service is usable only with that service, and requiresusers of its online component to be CompuServe® member/subscribers, onterms such as described above, which terms restrict the CD-ROM product'smarketability. The CD-ROM content and user interface is limited to thatprovided by CompuServe® Accordingly, such a dedicated CD-ROM service isnot a satisfactory solution to independent publishers looking foreconomical update means, because they will be limited to whatever userinterface and data management flexibility the online vendor may providewhich will substantially restrict any creative look-and-feel identitythe publisher may have provided in their own product. Thus the CD-ROMproduct is described by CompuServe® in the statement: “It is,essentially, a new window on CompuServe . . . ” This product descriptiondoes not suggest an ability to obtain updated online information forintegrated local, offline use with an original information productstored on the CD-ROM, as is provided by the present invention.

In addition to CD-ROM-based products, various new informationdistribution methods and services are made possible by embodiments ofthe present invention. The object source can be a remote server equippedwith a cooperative communications module closely molded to workeffortlessly with the information transporter for distributing objectsto a wide base of users. Such a remote server can be linked to a vendoror gatewayed to other information object sources or electronicpublishers, and exploit its smooth and efficient information transportcapabilities to act as a distribution point for such vendors, sources orpublishers.

Thus, the invention further comprises such a special-purpose serverdesigned for use with the novel information transporter and thespecial-purpose server can be established as a distribution service forpublishers who incorporate the information transporter in theirproducts. The invention also provides a method of operating a server toprovide such a software service and server-enabling software.

CONCLUSION

The present invention has been described above with the aid offunctional building blocks illustrating the performance of functions andrelationships thereof. At least some of the boundaries of thesefunctional building blocks have been arbitrarily defined herein for theconvenience of the description. Alternate boundaries can be defined solong as the specified functions and relationships thereof areappropriately performed. Any such alternate boundaries are thus withinthe scope and spirit of the claimed invention.

It is to be appreciated that the Detailed Description section, and notthe Summary and Abstract sections, is intended to be used to interpretthe claims. The Summary and Abstract sections can set forth one or more,but not all exemplary embodiments of the present invention ascontemplated by the inventor, and thus, are not intended to limit thepresent invention and the appended claims in any way.

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. It will be apparent to persons skilledin the relevant art that various changes in form and detail can be madetherein without departing from the spirit and scope of the invention.Thus, the breadth and scope of the present invention should not belimited by any of the above-described exemplary embodiments, but shouldbe defined only in accordance with the following claims and theirequivalents.

1. A computer implemented method for transacting electronic commercebetween a remote computer system and a user station over acommunications network, at least a portion of which includes theInternet, comprising: during a first user-initiated communicationssession, receiving at the remote computer system user stationinformation for a user station not previously identified to the remotecomputer system from the user station for storage remote from the userstation, providing user station identification information from theremote computer system to the user station for automatic storage at theuser station, creating an association at the remote computer systembetween the user station identification information and the user stationinformation, and using at the remote computer system the user stationinformation when processing a first purchase transaction; and during asecond user-initiated communications session subsequent to and separatefrom the first user-initiated communications session, receiving at theremote computer system the user station identification informationautomatically accessed on the user station, and accessing the storeduser station information using the remote computer system and thereceived user identification information when processing a subsequentpurchase transaction associated with the communications session.
 2. Acomputer implemented method for transacting electronic commerce betweena remote computer system and a user station over a communicationsnetwork, at least a portion of which includes the Internet, comprising:during a first user-initiated communications session, receiving at theremote computer system user information for a user not previouslyidentified to the remote computer system from the user station forstorage remote from the user station, providing user identificationinformation from the remote computer system to the user station forautomatic storage at the user station, creating an association at theremote computer system between the user identification information andthe user information, and processing a first purchase transaction usingat the remote computer system the user information; and during a seconduser-initiated communications session subsequent to and separate fromthe first user-initiated communications session, receiving at the remotecomputer system the user identification information automaticallyaccessed on the user station, and accessing the stored user informationusing the remote computer system and the received user identificationinformation when processing a subsequent purchase transaction associatedwith the communications session.
 3. A computer implemented method fortransacting electronic commerce between a remote computer system and auser station over a communications network at least a portion of whichincludes the Internet, comprising: during a first user-initiatedcommunications session, receiving at the remote computer system userinformation for a user not previously identified to the remote computersystem from the user station for storage remote from the user station;sending user identification information from the remote computer systemto the user station for automatic storage at the user station bysoftware running at the user station; creating an association at theremote computer system between the user identification information andthe user information; using at the remote computer system the userinformation when processing a first purchase transaction; during asecond user-initiated communications session subsequent to and separatefrom the first user-initiated communications session, receiving at theremote computer system from the user station the user identificationinformation automatically accessed by the user station; and using at theremote computer system the user identification information to gainaccess to the stored user information when processing a subsequentpurchase transaction associated with the communications session.